Bug#978636: move to merged-usr-only?
On Tue, 26 Jan 2021 at 10:30:34 +0100, Bastian Blank wrote:
> On Tue, Jan 26, 2021 at 09:01:12AM +0000, Simon McVittie wrote:
> > On Tue, 26 Jan 2021 at 08:02:06 +0100, Bastian Blank wrote:
> > > 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"?
>
> "We allow packages to ship files". So either we force all packages to
> only ship files in /usr/*, instead of e.g. /bin. Or we continue with
> status quo, where packes may use either /bin or /usr/bin, which is part
> of the current mess.
Oh, I see. So when you say "both" in 1a, you're referring to the overall
system - like the fact that we have both /bin/bash and /usr/bin/perl.
I don't see how we can force all packages to only ship files in /usr/*
(your 1b), except by either *first* moving to merged-/usr-via-aliasing
(layout 1, which in this case would have to be your 1a because it has to
happen before we can have 1b), or introducing new functionality in dpkg
and waiting another release cycle or two to make it guaranteed-to-exist.
Rationale:
* bash and libc6 are Essential
(so are other packages, but these two are enough to demonstrate my point)
* bash has traditionally shipped /bin/bash, and this is part of its
Essential interface (other packages ship #!/bin/bash scripts)
* libc6 ships /lib/ld-linux.so.2 and other architectures' equivalents,
and this is part of its Essential interface
(other i386 packages have ELF interpreter /lib/ld-linux.so.2)
* Essential packages are required to be functional after being merely
unpacked, not configured (otherwise debootstrap can't work)
So if we unpack bash and libc6:i386, but do not configure them, /bin/bash
and /lib/ld-linux.so.2 must exist in the resulting chroot.
If that chroot is *already* mandated to be merged-/usr-via-aliasing
(layout 1), then it would be fine for bash's filesystem tarball
to contain ./usr/bin/bash and libc6's filesystem tarball to contain
./usr/lib/ld-linux.so.2, because the /bin -> usr/bin and /lib -> usr/lib
symlinks take care of keeping those packages' Essential interfaces intact.
However, if that chroot is in layout 2a or 2b, and bash's filesystem tarball
contains ./usr/bin/bash, then its Essential interface is incomplete:
there will be no /bin/bash symlink until the package is configured
(maintainer scripts are run).
I agree that your 1b is preferable *eventually*, but I think your 1a is
necessary as a stepping-stone to get there.
The only other option that I can see is for dpkg to gain the ability to
populate what we might call the "mergeable" directories (/bin, /sbin,
/lib*) in a purely declarative way, during unpack. If that isn't introduced
until Debian 12, then the packages in Debian 13 would be the first that
can rely on that feature existing.
smcv
Reply to: