On Tue, 11 Jul 2023 at 09:44, Helmut Grohne <hel...@subdivi.de> wrote: > > 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.
Interesting - I guess from here from the original mail: > On the flip side, there is a demo for #3c showing that we can move most > of the things except for a hand full of packages and then flip the > switch (for bootstrapping) in unstable by uploading those packages > simultaneously. The biggest downside of this probably is the inherent > fragility of this approach. Even if this is extensively tested before > uploading chances are good that we still break something unforeseen in > the process. in my head 'uploading' became associated with 'updating', so I thought the implementation of this process required some precise runtime constraints. Good to know that it's not the case then. > > 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? Nothing, as that stemmed from a misunderstanding of what the implementation would have required, and that's cleared now. Kind regards, Luca Boccassi