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 <hartm...@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