Bug#978636: move to merged-usr-only?
On Tue, 26 Jan 2021 at 12:17:37 -0600, Gunnar Wolf wrote:
> Wouter Verhelst dijo [Tue, Jan 26, 2021 at 01:17:38PM +0200]:
> > We can (and should, IMO) declare *today* that for bookworm, shipping
> > files in / (as opposed to /usr) that are not compatibility symlinks will
> > be RC.
>
> I agree with you
For at least the Essential packages like bash and libc6, I don't think
we can go in that order. Given that implementations of merged /usr via
aliasing symlinks already exist, I think Essential packages that ship
part of their Essential functionality in /bin, /sbin, /lib* must stay
as they are now, until after we have had a flag day (a release)
at which either:
a. those aliasing symlinks are guaranteed to be in place (Ansgar's request
in this bug)
b. those aliasing symlinks are forbidden and must be rolled back (Guillem's
preferred answer to this, but judging by #914897 and discussion of this
bug, very unlikely to be the technical committee's preferred answer)
That's because these two axioms collide:
* Essential packages must provide their Essential functionality while
unpacked but not configured
- e.g. unpacking libc6:i386 creates /lib/ld-linux.so.2, which is Essential
functionality that other packages rely on
* There are existing installations with merged /usr via aliasing symlinks
- Therefore compatibility symlinks (in either direction!) must be created
by a maintainer script rather than directly shipped in the
dpkg --fsys-tarfile, otherwise they will fail to unpack on those existing
systems
- e.g. if unpacking libc6:i386 creates /usr/lib/ld-linux.so.2, then it
cannot also create /lib/ld-linux.so.2; that would have to happen
later, when it's configured
I don't see a way to have a compromise position in Essential packages,
other than the one we have right now (where the name in the
dpkg --fsys-tarfile must match other packages' expectations, whether
that means with or without /usr), without breaking the Essential
property.
When thinking about this transition (and any contentious issue, really),
please distinguish between:
- things that (in someone's opinion, maybe yours) we *shouldn't* do;
- things that (according to properties we take as axiomatic, like the
Essential property and the requirement that upgrades work) we *can't* do
I have been trying hard to consider all the options that are available -
even the ones that I personally think we *shouldn't* do - but immediately
dismiss the ones that we *can't* do.
smcv
Reply to: