Dear maintainers of relevant essential packages,
this /usr-merge transition covering multiple release has reached a point
where consensus has been reached about completing it by moving files
from / to /usr. The chosen approach also affects filesystem bootstrap
and an earlier discussion of this matter has resulted in consensus for
not changing the bootstrap protocol from the pre-/usr-merge state and
rather returning to that state. To this end, debootstrap has been
updated in trixie and unstable such that it performs the initial unpack
before performing the merge (mirroring how usrmerge does it on existing
systems). This change is being backported to bookworm and bullseye by
Simon McVittie. In order to remove the usrmerge package eventually, we
want base-files to install the aliasing symlinks via its data.tar.
Unfortunately, we cannot just do that, because doing so would break
debootstrap or cdebootstrap/mmdebstrap or both.
The way we get there is to first convert all packages from the
Priority:required set but some exceptions to install no files into
aliased locations such as /bin, /sbin or /lib*. Getting there will
consume months. I hope we can reach this state in early 2024.
Once the Priority:required set only has that exception set left
unconverted, I will prepare patches for the entire exception set and
upload it coherently in one dinstall window.
That exception set is:
* base-files
* bash
* coreutils maybe
* dash
* libc6
* util-linux
base-files will install /bin, /sbin and /lib as symbolic links in its
data.tar. libc6 will install multilib /lib* where needed as symbolic
links in its data.tar:
* /lib64: amd64, loong64, mips64el, ppc64, ppc64el
* /libx32: x32
Since the relevant architectures share their libc soname, these packages
will remain multiarch co-installable. Multilib symlinks that are not
essential to a Debian architecture are not installed in a data.tar and
managed using maintainer scripts instead. For instance, /lib64 will not
be a symlink in libc6-amd64:i386, because /lib64 is not essential to
i386 nor is libc6-amd64:i386 essential to i386.
If we were to upload base-files before other packages, then a
bootstrapping tool could first unpack that other package thereby
creating e.g. /bin as a directory and then extracting the symbolic link
from base-files' data.tar would fail.
If we were to upload any other package from that set before base-files,
the aliasing links would be absent and merging via usrmerge.postinst
would not work due to missing the dynamic linker, /bin/sh, /bin/bash,
or /bin/cp. Running util-linux.postinst before usrmerge.postinst could
fail for the absence of /bin/more.
Therefore changes need to be uploaded concurrently. I intend to perform
these uploads in coordination with you. I request permission to NMU your
package for the purpose of completing the transition in this way.
Before actually performing such a NMU, I will prepare and send the
to-be-NMUed patches to all affected maintainers for review. The purpose
of having these NMUed is meeting the concurrency requirement. If you
insist on performing the upload yourself, you could arrange handing me a
signed .dsc.
These packages also need to migrate to testing together or we will
temporarily break bootstrappability of testing. We can either ensure
that by temporarily adding suitable Breaks or using special release team
powers.
I will coordinate a suitable time avoiding e.g. a glibc transition or a
time64 transition.
I will try to remove coreutils from the exception set by changing
usrmerge to no longer require a particular location of cp.
I request that affected maintainers reply to this mail:
* Are you ok with the proposed changes in principle?
+ Moving all files from / to /usr leaving no files in aliased
locations
+ Installing aliasing symbolic links in base-files and libc6
* Are you fine in principle with me NMUing your package after having
reviewed the promised patch?
* Do you readily see any flaw in the proposed transition already?
Thanks for your cooperation
Helmut
