Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)
Hi Johannes,
On Fri, Jun 09, 2023 at 05:47:56PM +0200, Johannes Schauer Marin Rodrigues wrote:
> if I understand that plan correctly, the usrmerge-support package setting up
> diversions is only necessary because you want to avoid having to do the move to
> /usr of *all* affected packages in the essential set in a single dinstall? Is
> that correct?
This is not correct. In bookworm -> trixie upgrade scenario, we intend
to move all the files from / to /usr. Now we look into how this happens
focus on one particular symlink, without loss of generality choose /bin.
Since /bin is no longer in the dpkg database at the end of the upgrade,
some package must be the last one to contain /bin. When upgrading (or
removing that package), dpkg will attempt to remove /bin (which in its
opinion is an empty directory and the last consumer is releasing it).
However, since dpkg has no clue about file types, it doesn't actually
know that this is a directory and takes care of the /bin -> /usr/bin
symlink using unlink(). And this is where /bin vanishes. Oops.
So the idea here is to add a protective diversion for /bin such that
removing /bin instead removes some path we don't care about. The
important thing now is that every package that moves stuff from /bin to
/usr/bin needs to ensure that this diversion exists. We can achieve that
in one of two ways. Either that some package (and with that I mean every
package that ships stuff in /bin, because we cannot predict which
package will be last) gains a preinst that sets up this diversion (on
behalf of base-files) or it Pre-Depends on some package that handles
setting up this diversion. It seems rather obvious that we might just
have a versioned "Pre-Depends: base-files (>= version that introduces
the diversion)", but then we get a pre-dependency loop from base-files
via an awk implementation to libc6 and then (via this new Pre-Depends)
back to base-files. So base-files cannot be the package that we list in
Pre-Depends here. And this is where usrmerge-support comes into the
picture. Any package that moves stuff out of one of the aliased
directories gains a Pre-Depends: usrmerge-support to protect the
aliasing symlinks from deletion.
Please note that this hasn't been obvious to me at all. I totally didn't
see this pre-dependency loop coming until dpkg told me when I actually
tried this.
So this usrmerge-support package very much is not for reducing that set
that we have to upload in one dinstall, but for making smooth upgrades
work at all.
This really is an important detail and I'm sorry for having missed it in
my previous mail. Thanks for asking.
> If yes, how many source packages are we have to be modified part from
> base-files, dash, bash, libc6, and util-linux?
Given the above, I think this no longer is relevant.
> Would it be too much to prepare patches for all of these, test that everything
> works with some QA setup and then NMU all 22 source packages with pre-approved
> patches in a single dinstall? Would that avoid having to temporarily go via a
> usrmerge-support package?
I have considered this approach and if it gains us something I
definitely see it as something to consider, but given the above, it
doesn't save us from usrmerge-support.
The other thing that we need usrmerge-support for is the dpkg-divert
wrapper. Any package that contains an aliased diversion or moves a
diverted file from an aliased location will likewise have to gain a
pre-dependency on usrmerge-support. Again, we cannot do this in
usr-is-merged, because that would kick usrmerge out of the default
essential set and thus break mmdebstrap.
Helmut
Reply to: