On Tue, 26 Jan 2021 at 08:02:06 +0100, Bastian Blank wrote:
> On Mon, Jan 25, 2021 at 09:22:29PM +0000, Simon McVittie wrote:
> > Some developers seem to be using "merged /usr" to refer to multiple
> > concrete layouts:
> > 1. an arrangement where all regular files that have traditionally been
> > in /bin, /sbin, /lib and /lib64 are physically located in /usr,
> > with symlinks /bin -> usr/bin, /sbin -> usr/sbin, /lib -> usr/lib,
> > /lib64 -> usr/lib64
> > (this is what usrmerge, debootstrap --merged-usr and Fedora do; dpkg
> > maintainer Guillem Jover refers to this as "merged /usr via aliased
> > directories" which seems like a good unambiguous term)
>
> Aren't there two sub-solutions?
>
> 1a. with packages shipping files both in /bin und /usr/bin.
> 1b. with packages shipping files only in /usr/bin.
What precisely do you mean by "shipping files"?
If the content of the .deb (as in dpkg --fsys-tarfile) included both
/bin/bash and /usr/bin/bash, then the package would fail to install on
systems where the aliasing symlinks already exist (unless there was a
special case for this situation in dpkg, which would require at least one
more release cycle before we could do it). Given that Debian 10 systems
with the aliasing symlinks already exist, I think we can probably
rule that out as not a practically available solution for Debian 12.
If the content of the .deb only included /usr/bin/bash, relying on an
externally-constructed /bin -> usr/bin symlink to ensure that the path
/bin/bash is resolvable, then that's the logical conclusion of layout 1,
but is not something we can do until *after* there has been a release
in which layout 1 is the only thing we support (with systems not already
in that layout undergoing a migration step whose precise implementation
is outside the TC's scope - usrmerge.deb is one implementation of that
migration step, but perhaps someone will design something better).
I believe Ansgar's goal in opening this bug was to make Debian 12 the
first release in which layout 1 is the only thing supported, allowing
the transition to this form of .deb content to start (and maybe finish)
during the Debian 13 cycle.
If the content of the .deb only included /usr/bin/bash, with a maintainer
script to create /bin/bash if the aliasing symlink /bin -> usr/bin does
not already exist, then that's compatible with either 1, 2a or 2b - but
in the case of Essential packages that have traditionally installed files
to /bin, /sbin or /lib, it's incompatible with the traditional layout
with a distinct /bin and /usr/bin (etc.), due to the extra requirements
placed on Essential packages.
I think at least the Essential subset needs to continue to have files in
/bin, /sbin, /lib in their dpkg --fsys-tarfile until *after* a transition
to (some form of) merged /usr has been completed, otherwise Essential
packages that have merely been unpacked and not configured will not
be providing their Essential functionality at paths like /bin/bash and
/lib/ld-linux.so.2 that other packages rely on.
But perhaps I misunderstood you and you mean something else?
smcv
