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
    - 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

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.


Reply via email to