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
