Re: Second take at DEP17 - consensus call on /usr-merge matters
On Tue, 11 Jul 2023 at 09:44, Helmut Grohne <helmut@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
Reply to: