Re: Second take at DEP17 - consensus call on /usr-merge matters
Hi Luca,
On Tue, Jul 11, 2023 at 12:27:04AM +0100, Luca Boccassi wrote:
> You have said in the original mail and on the writeup that this option
> requires all the affected packages to be upgraded at the same time,
> and in the correct order, or things will break. What happens if any of
This definitely is a misunderstanding. At this time, I am not sure where
that misunderstanding originated and I don't even think it is worth
figuring out, but I wont mind a reference either.
I meant to say that the option requires the involved (~10) packages to
be *uploaded* (rather than upgraded) at the same time. And that
requirement originates from the bootstrapping aspect rather than an
upgrading aspect. Bootstrapping will be broken from the point in time of
the first upload of that set until the last package from that set has
been built.
I would not dare propose a solution that'd require upgrades to happen in
a specific order or way that is not expressible to apt. My impression is
that we have significant consensus on smooth upgrades being a core
feature of Debian. This should have failed your plausibility filter.
> those packages are held back, for whatever reason? This is the
> fragility aspect that I am worried about, and that is not an issue at
> all if we just fix mmdebstrap to do the right thing as debootstrap
> already does.
There are two mechanisms that shall ensure that any (valid according to
relationships) order and and held packages (up to not performing the
operation) will work. One is the Pre-Depends on usrmerge-support. If you
pin that package as absent for otherwise force its absence, apt will
simply refuse to upgrade everything else and your system will be stuck
at upgrading entirely. If you hold back any other package, it may keep
shipping files in aliased locations. The protective diversion mechanism
(DEP17-M4) will ensure that this does not cause the aliasing links to
disappear if you upgrade it later.
After having sorted this out, what part of your safety concerns with 3C
do remain?
I see that Sam and Guillem dislike my proposal of abusing diversions in
this way, but I honestly see little alternatives for doing this in a
safe way. In essence, we are introducing a symlinks vs directory
conflict for the aliasing symlinks and if anything goes wrong you may
end up without /bin/sh or the ELF loader. While diversions were not
meant for this situation, reasoning about them is relatively straight
forward for the purpose of what we need here. Critically, we don't need
any properties about the renamed location and we only need the property
that dpkg leaves the diverted location unmodified. I fully acknowledge
that I propose using diversions outside their specification. However, we
already use dpkg outside its specification in general (due to having
merged /usr). As such, we already have entered the land of relying on
implementation-defined behavior. Raphael's mitigation of making dpkg
more careful about deleting aliased files (DEP17-M3) also is about
temporarily extending dpkg in such an implementation-defined way. The
reason why I see diversions as favourable here is that they are a
similarly ugly mechanism that is readily available in the upgrade to
trixie and that all of them are of varying temporary nature:
* DEP17-M4: We need these from the point in time where we start moving
files out of aliased locations until the point in time where
base-files has recorded all aliasing links in the dpkg database. From
an unstable pov, this is probably is less than a year. From a
bookworm->trixie pov, the diversions will be added and removed during
the upgrade.
* DEP17-M6: The diversion of dpkg-divert is not a protective diversion
and is probably needed in trixie and forky.
* DEP17-M8: These protective diversions are short lived during an
individual package upgrade from preinst to postinst.
* DEP17-M9: These protective diversions are longer lived. They probably
need to be present in trixie. I hope that the majority of cases can
rather delete an unnecessary empty directory than set up a diversion.
* DEP17-M10: These protective diversions are short lived during an
individual package upgrade from preinst to postinst.
* DEP17-M14: The diversion of update-alternatives is not a protective
diversiion and is probably needed for trixie and forky.
You see that the majority of these diversions is short lived. Since I
propose introducing them on-demand rather than automatically, their
number should be low. If it were not the case that this abuse of
diversions were temporary, I would be opposed to it. What makes it
attractive to me is that the alternatives also seem to be abusing dpkg
and the diversion abuse works right now.
Helmut
Reply to: