Re: Second take at DEP17 - consensus call on /usr-merge matters
Hi Helmut,
Let me restate once again that I think you are doing a stellar job at
tackling this problem, and you have my thanks for it. From what I can
see, I think 99% of us are on the same page for 90% of the problem.
The remaining part on how to make bootstrapping safe is the last bit.
And in the end it is not a big deal, if consensus is going the other
way, that's fine, let's do that and get this over with. However until
we get there, I must say I still agree with Sam:
On Sat, 8 Jul 2023 at 14:58, Sam Hartman <hartmans@debian.org> wrote:
> * You do not talk much about upgrades. Upgrades happen against a moving
> archive.
> There, talking about the changes, and why the changes are always safe
> is important.
>
> So for me, a 3C proposal would have two components:
>
> 1) An explanation of what the archive looks like at time of bootstrap
> (and changes to any bootstrap programs) so I can reason about whether
> bootstrap works.
>
> 2) An argument of safety of upgrades focused on the changes and why
> those changes are safe both for unstable upgrades and for bookworm
> upgrades.
>
> * Your debootstrap changes seem overly complicated and would in and of
> themselves push me against 3C. First, you don't seem to be thinking
> about buster, which also needs to bootstrap usrmerged, doesn't it.
> Second, is there a way we could simply change how debootstrap calls
> tar?
> I think asking debootstrap to not create the symlinks before is a big
> ask.
I have not spent as much time as you have, so I do not have
reproducers or such things for what worries me, only a general sense
that I agree with the above - I think for 3C the upgrade flow is
under-documented. I am not worried about how bootstrap works in that
case. As already mentioned, I think if bootstraping a new sid chroot
is borked for a day or two it's not the end of the world - it happens,
it's sid.
The upgrade path however affects every running machine there is.
unstable -> unstable first, then testing -> testing, and then
oldstable -> stable in the future. Having complex machinery there
sometimes is just necessary, and it comes with important caveats. See
the usrmerge package for example - we needed to do a live conversion
for old systems, so it was necessary to have it, and it works well,
however it has corner cases that it just cannot handle (eg: overlay
where the OS is the base layer) and where we just raise our hands and
nope out. I don't know if what you propose would have similar issues
or not, but given there _is_ an alternative here to fix bootstrapping
that doesn't require delegating complex machinery to the packages
themselves, I very much prefer that, as to me it obviously seems
inherently less risky.
Kind regards,
Luca Boccassi
Reply to: