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