Re: Second take at DEP17 - consensus call on /usr-merge matters
Hi Sam,
On Fri, Jul 07, 2023 at 08:50:49AM -0600, Sam Hartman wrote:
>
> TL;DR:
> It looks like if we do not want to encode merged /usr into the bootstrap
> protocol, we must keep some aliases and cannot move all files in
> data.tar.
Reading both of your recent mails left me very confused. It is now
obvious to me that we have a misunderstanding (at least one) and I am
not exactly sure how we can get to a point where we talk about the same
things.
In your second mail, you classify 3C (the one about not changing the
bootstrap protocol by adding aliasing symlinks to base-files) as a
category 1 solution (where we leave some files in their aliased location
to facilitate bootstrap). In reality, 3C is fully incompatible with
category 1 as the premise of 3C is that every essential package has all
of its files moved. This directly contradicts your TL;DR here.
Let me try to ignore much of the past conversation and instead explain
the bootstrap-relevant part of the transition plan that I see as
favourable (i.e. 3C). Consider this an opinionated presentation for one
of multiple ways to move forward.
We first move towards a category 1 solution where we move files to their
canonical locations as much as possible without breaking the current way
of bootstrapping that relies on either pre-creating the symlinks
(debootstrap) or usrmerge.postinst (mmdebstrap, cdebootstrap). This
process has lots of non-obvious details that I'll skip for the sake of
the bootstrap topic here. Let us for a moment assume that we'd manage to
get to this category 1 solution where most files (in essential packages)
have moved their files to canonical locations and we're left with some
packages (e.g. libc6, dash, util-linux, ...) that could not move their
files.
There is one aspect, I want to get into more detail as it is partially
relevant to bootstrapping and this is protecting the aliasing symlinks
(DEP17-P9). Here, I am selecting DEP17-M4 as the relevant mitigation.
That amounts to adding a usrmerge-support package that creates
protective diversions for the aliasing symbolic links and assigns them
to base-files. Both base-files and any package that moves files out of
aliased locations has to gain Pre-Depends: usrmerge-support in order for
this method to be effective. So we'll likely see debhelper's
${misc:Pre-Depends} that we added for multiarch-support return.
Until this point, we can still decide whether we do 3B or 3C and I am
explaining what happens in the 3C choice now.
Concurrently with the earlier changes, we modify debootstrap.
debootstrap requires uploads to bookworm and bullseye anyway, because we
will have to change --variant=buildd to become merged for trixie and
forward while currently debootstrap always creates --variant=buildd as
unmerged. On top of this necessary change, we add a change relevant to
3C. Currently, debootstrap creates the aliasing symbolic links prior to
the initial package unpack. I want to swap these operations. In doing it
afterwards, debootstrap cannot just create the symlinks but may have to
perform an actual merge in much the same way that usrmerge does now
except for dropping the atomicity requirement (as we don't need that in
the bootstrap setting). Other than that, this change is fully backwards
compatible (since bootstrapping as unmerged and the installing usrmerge
also works) and will continue to debootstrap a merged bullseye, bookworm
and trixie in the same way as before. I'll get into why we do this in a
moment.
Then, we assume that updating debootstrap has happened, usrmerge-support
exists in trixie and the number of essential packages shipping files in
aliased locations is about 10. We now move away from category 1. At this
point my original categorization becomes a little difficult, so I defer
explaining what we move to. We prepare changes to canonicalize all those
remaining packages (only essential ones) to canonicalize their paths and
also prepare a change to base-files to change the type of the aliasing
symlinks from directories to symlinks. While it technically is a
directory-to-symlink conversion from a dpkg point of view, that
conversion has already happened on the filesystem level, so this
practically is a change to the dpkg database only. Now we upload all of
these packages concurrently. This is when mmdebstrap and cdebootstrap
temporarily break. Once all of the binary packages have been built and
installed into the archive, things should work again.
Due to having modified deboostrap, we arguably have moved into category
4. Since that change is backwards-compatible and has been uploaded to
bullseye and bookworm, we can kinda pretend that the bootstrap protocol
never was different and therefore say that we move into category 2, but
without the reasons originally given for why this cannot work. Had we
skipped that change to debootstrap, unpacking base-files would make
debootstrap fail, because it passes -k to tar and when tar would try to
create the /bin -> usr/bin symlink included in base-files, tar would say
that it already exists (due to debootstrap having created that same link
beforehand) and fail (due to -k). In swapping the order, base-files
would succeed with unpacking and the merging step would identify that
nothing has to be done here. For mmdebstrap and cdebootstrap, nothing
changes. They just unpack all the files and since base-files ships the
aliasing links, we end up with a merged-/usr system without involving
any protocol changes or scripting on their side.
Please don't understand this as "this is how we must be doing it". This
is one of multiple approaches and selects (possibly suboptimal)
trade-offs in a number of occasions, but it is the one that I and
Johannes currently prefer. At the time of this writing, this definitely
is not consensus. The proposed change to debootstrap does not have code
yet, but I am positive that it is feasible, because the usrmerge package
effectively is a proof-of-concept, and I'm up to doing the
implementation. That earlier mail has a test-usrmergebootstrap.sh script
attached that prototypes many of the other aspects of this. It has a
demo (called "movemost") for the category 1 change implemented by
binary-patching packages and it also has a demo (called "movefull") for
this very 3C change and shows that these binary-patched packages work
with unmodified mmdebstrap an cdebootstrap as well as succeeding an
upgrade from unstable to patched-unstable. The demo also shows how an
unmodified debootstrap fails to unpack base-files due to -k in that 3C
scenario.
When it comes to judging the risk of this, I see two main areas where
things can go wrong. One is that change to debootstrap which has to be
backported to bullseye and bookworm. That part seems relatively testable
to me and we get a significant part of that risk anyway due to that
--variant=buildd aspect.
The other part to this is messing up the concurrent upload of ~10
essential packages. Again, I hope that sufficient testing can put us
into a place where the resulting failure affects a minority of use
cases. An obvious candidate that I have broken repeatedly is piuparts.
The major risk here arises from this becoming a flag-day transition from
a fsbootstrap point of view. If any of the packages in unstable involved
in bootstrap were to ship any file in aliased locations and it were
unpacked before base-files by the bootstrapping tool (and the order of
unpacks is undefined), then bootstrapping were to fail when unpacking
base-files. That set of packages involved here is relatively small
though which makes that risk acceptable to me. And even if that were to
happen, the DEP17-M4 mitigation would make that mostly harmless for
package upgrades.
In any case, let me explicitly agree with you that any category 1
solution (i.e. one where we skip moving some of the files) poses an
unreasonable long-term cost as we might have to move back files when
maintainer scripts need new functionality early in the bootstrap.
I hope that this mail resolves much of the misunderstanding. I also hope
that after having misunderstandings resolved, much of the disagreement
disappears. And finally, I hope that you made it to the end of this. It
really got quite long again, but I fear that doing it any shorter would
have resulted in more misunderstandings.
Helmut
Reply to: