On Oct 18, Sean Whitton <spwhitton@spwhitton.name> 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)

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)