1. Forum
  2. Usenet
  3. LINUX.DEBIAN.DEVEL

  • Re: tech-ctte: More specific advice regarding merged-/usr and implicati

    From Marco d'Itri@21:1/5 to All on Mon Oct 18 23:10:02 2021
    On Oct 18, Sean Whitton <[email protected]> wrote:

    Thank you: this is great work and, even if it requires maintaining
    support for unmerged systems for yet another release, I fully agree with
    the results.

    - Debian contributors who are interested in merged-/usr are invited to
    implement a straightforward migration path from non-merged-/usr to
    merged-/usr. The Technical Committee will not design this migration
    path in detail. If disputes arise related to this migration path, or
    if advice on this migration path is requested, we will resolve those
    by following our usual procedures.

    + One example of a migration path that might be used is for an
    Essential package to add a dependency on the usrmerge package, so
    that it will be installed automatically during upgrades. We do not
    require this to be the migration path that is chosen; it is
    presented here merely to demonstrate that such a migration path
    can exist.
    This looks like a good plan. I am not sure that alternative ones
    which fit the other requirements have ever been proposed, but I would
    still like to hear about them if anybody has better ideas.

    This is a rough sketch of a possible solution:

    Package: foo
    Essential: yes
    Depends: usrmerge | usr-is-merged

    Source: usrmerge
    Package: usrmerge
    Provides: usr-is-merged

    Source: usrmerge
    Package: usr-is-merged
    Description: this is an empty transitional package
    It can be removed as soon as no other package depends on it.
    .
    It fails in preinst if /{bin,sbin,lib*} are not a symlink.
    .
    It is useful to satisfy the dependency without bloating already
    converted systems.

    An open question: how do we make debootstrap and its clones install usr-is-merged instead of usrmerge?

    So, who is willing to be the maintainer of "foo"?
    There are not too many candidates:

    grep-available -s Package -F Essential yes | uniq | less

    --
    ciao,
    Marco

    -----BEGIN PGP SIGNATURE-----

    iHUEABYIAB0WIQQnKUXNg20437dCfobLPsM64d7XgQUCYW3haAAKCRDLPsM64d7X gR7UAQCfCDD2tSLovRgRVMFy+4a1VEM2wk/P/yOGGHPKEQ9RFgEAzOcEKjX1Q+Xy VOPZ4CtFlH3SXXdQM6LzK8kWz1oFjAg=
    =btKc
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Richter@21:1/5 to All on Wed Oct 20 10:00:05 2021
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iz9TftL4YDfTxRZHI0DJrU0ylzUDRfdE0
    Content-Type: text/plain; charset=windows-1252; format=flowed
    Content-Language: en-US
    Content-Transfer-Encoding: quoted-printable

    Hi,

    + One example of a migration path that might be used is for an
    Essential package to add a dependency on the usrmerge package, so
    that it will be installed automatically during upgrades. We do not
    require this to be the migration path that is chosen; it is
    presented here merely to demonstrate that such a migration path
    can exist.

    This looks like a good plan. I am not sure that alternative ones
    which fit the other requirements have ever been proposed, but I would
    still like to hear about them if anybody has better ideas.

    I have proposed one in the past that can avoid bypassing dpkg, and that includes a mechanism for making the dpkg database consistent with
    reality again (which is a requirement for lifting the moratorium on
    moving files).

    The latter cannot be achieved from any package besides dpkg anyway, so
    any solution needs to be implemented there; this also obviates the need
    for the usrmerge package going forward.

    I've since found a complication during the unpack phase of a new
    installation with my proposal, so I've modified it a bit:

    My approach:

    - Define a new control file, "transitional-symlinks", that indicates a
    desire to move a directory subtree when symlinks cannot yet be shipped
    inside packages conflict-free.
    - Include this control file inside the base-files package, , and add a Pre-Depends on a version of dpkg that understands this control file
    - dpkg uses both the contents of this control file and symlinks inside packages that conflict with directories in other packages to transform
    its database.

    My original proposal was just to redefine the handling of
    symlink-vs-directory conflicts (which are currently resolved in dpkg by ignoring the symlink), but this is not sufficient, as shipping proper
    symlinks in base-files would lead to an error when debootstrap/cdebootstrap/multistrap/... unpacks all Essential packages
    to get a minimal environment up.

    After the next stable release, we can then replace the control file with regular symlinks shipped inside the package.

    Simon


    --iz9TftL4YDfTxRZHI0DJrU0ylzUDRfdE0--

    -----BEGIN PGP SIGNATURE-----

    iQEzBAEBCgAdFiEEtjuqOJSXmNjSiX3Tfr04e7CZCBEFAmFvyX0ACgkQfr04e7CZ CBHG5gf9FlLfdvxzox2/hjF6hzwWhHCMY9HgSA20YEacXd6utxWf0Zk1xGbfjeft erKQnRaRL7184rPK5Mirb59UTQfihZ21vcVmTNk57gjQsyxpfLCNZnHFxFd0W4nm UY3XERtDdptxZSXlcoRvVaPIKcM80OO0h+V2It7koMC5iXvri4NCMGvmFHAxEVFB gIjfODpTO16LF+41KpaSrIFJetrGSCAfyuKUCKaaYahhCgRAIU2A94VfgIJDt2G6 2+eLlwYEP/l05yQJ+D02/0lkTsX8GykJ+oHr0oN+OHkuA0XQehNNhwis7ll6kBAO QOVEAvCvZg1nhS5RJ8aq9JfSCrFMqg==
    =Qafj
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)