Lifting the moratorium
Hi,
after bookworm, we extended the moratorium, because we saw that lifting
it would cause problems. We have a better understanding of those
problems now and are into preparations for actually moving files. I'd
like to initiate a discussion on how the moratorium is to be lifted.
DEP17 tells us about known problem classes. Let me go through them with
a focus on how they interact with the moratorium.
P1 file loss due to concurrent canonicalization and move.
The moratorium currently prevents this. There is little we can do about
this class before lifting the moratorium as the intention is to mitigate
this case by case by upgrading Replaces to Conflicts (M7) or employing
protective diversions (M8). I note that since bookworm no packages have
been restructured in a way that would cause an immediate P1 problem for
systemd units just yet.
P2 ineffective trigger interest
This is not mitigated, but the moratorium keeps the practical effects
low. Patches for all affected packages in Debian have been filed. They
should be upgraded to RC severity before lifting the moratorium. The
only two instances not yet fixed in unstable are #1043419 and #1043420.
P3 ineffective diversions
The moratorium currently prevents this. We don't quite have agreement as
to whether this should be mitigated centrally (by doing something to
dpkg-divert M6) or decentrally (by duplicating all of the diversions in
packages M18). If the decentral approach is chosen, we will handle this
case by case. I note that since bookworm, there are no P3 instances for
systemd units left.
P4 disagreeing alternatives
The moratorium currently prevents this and the idea is that we continue
to use aliased paths for update-alternatives where they already are used
in such a way (M13).
P5 ineffective dpkg-statoverride
The moratorium currently prevents this, but this is an aspect that
maintainers will have to handle on a per-package basis anyway.
P6 Empty directory loss
This is not prevented by the moratorium, but lifting it will make it
worse. Bugs for all current issues have been filed and as packages move,
there will likely be five more instances. The idea is to handle them
case by case.
P7 Shared multiarch file loss
This is prevented by the moratorium. Lifting is likely to spawn a
two-digit number of such losses. Thus far, the idea is to handle these
case by case using protective diversions (M10). I note that no systemd
units are currently affected by this problem though a number of udev
rules will be.
P8 bootstrapping
The moratorium currently keeps bootstrapping working. debootstrap in
trixie is forwards compatible with what we're heading to. Moving files
in transitively essential packages from / to /usr is prone to breaking
mmdebstrap or cdebootstrap though. As such a limited moratorium should
be retained for now.
P9 Loss of aliasing links
The moratorium currently prevents them from being lost. Once large
amounts of packages are converted, aliasing symlinks may vanish. Such a
failure is prone to making end user systems unbootable. As long as
essential packages are not converted, this cannot be practically
experienced.
P10 debian-installer
The debian-installer is still unmerged. If the moratorium were lifted,
files could move to /usr (even in udebs) and thereby break the
installer. There is a MR trying to make it use a merged layout.
Beyond the numbered problems, keep in mind that buildds are not yet
/usr-merged. This also depends on a SPU of debootstrap for bullseye.
Takeaway
If you read through this list, we should recognize two recurring ideas.
Much of the preparation has been done or initiated and what's left in
large part is doing mitigations after having lifted the moratorium.
Lifting the moratorium isn't exactly boolean. More than half of the
packages that ship files in aliased locations only do so due to
containing a systemd unit. For essential packages, we want to do the
conversion at a later time.
This gives rise to the question of how to lift the moratorium. I suggest
that simply saying "no moratorium anymore" is prone to causing breakage.
Lifting the flood gates could cause uncontrollable fallout. A more
sensible approach could be lifting it for certain categories (e.g.
systemd units once debhelper is updated to recognize units below /usr)
or performing targeted uploads specifically aimed to resolving the
resulting problems (e.g. canonicalizing specific m-a:same packages while
simultaneously adding the necessary diversions or canonicalizing
packages containing dpkg-statoverrides while specifically handling
them).
You see that this goes into very much detail and having the CTTE decide
upon the precise way of lifting this seems suboptimal. That would amount
to micro-managing the transition. In effect, the most sensible way I see
forward is trusting our developers to the right things by formally
lifting the moratorium entirely and still asking them to be careful
about what they do. Then we could have a living document (not authored
by CTTE) describing what careful means precisely. With dumat being in
operation as a detection mechanism (though not yet performing
unsupervised RC bug filings), we've got the means to see what goes wrong
at least.
Does this make sense to you? Do you have other thoughts on how to move
forward on the CTTE side?
Helmut
Reply to: