On Thu, 29 Jun 2023 at 11:53, Johannes Schauer Marin Rodrigues <jo...@debian.org> wrote: > > Hi, > > mmdebstrap author here. This is the other bootstrapping tool which is > currently > sitting at ~17% of the popcon value of debootstrap. > > Quoting Helmut Grohne (2023-06-28 21:37:44) > > Once that is settled, the next big question is how to handle bootstrapping. > > We had a number of people arguing in favour of changing the bootstrap > > protocol. Such changes can be classified into generic changes and > > release-dependent changes. A release-dependent change enhances bootstrapping > > tools with knowledge of available releases and adapts behaviour in > > release-specific ways that are encoded into the bootstrapping tool. As it > > stands, the only bootstrapping tool that has been enhanced in this way is > > debootstrap and that support is limited to Debian and two derivatives. The > > category of generic changes includes imposing an ordering on initial unpacks > > (e.g. base-files first). Others are in favour of not changing the bootstrap > > protocol. In that view, some data.tar will have to ship the symbolic links > > and all other essential packages need to have their files canonicalized. > > > > Among these options, the first has a working prototype (debootstrap), > > but it is unclear how that extends to use of snapshot.d.o and how to > > make it work with debootsnap and debbisect as those tend to use a suite > > name rather than a codename. The last option has a prototype and relies > > on uploading a number of essential packages in a short window of time. > > (What could possibly go wrong?) > > > > It is not clear to me how we can get to a consensus on these, so the > > best I can do here is summarize options. > > > > Option #3a: > > > > The bootstrap protocol shall be changed to contain a task for > > merging /usr as is done in debootstrap in a release-dependent way. > > > > This is an instance of M16 from DEP17. > > > > Option #3b: > > > > The bootstrap protocol shall be changed in unspecified ways to > > support the /usr-merged systems in a way that does not depend on > > matching the codename or suitename. > > > > This is an instance of M16 from DEP17. > > > > Option #3c: > > > > The bootstrap protocol shall remain unchanged. Therefore, all > > essential packages need to move their files out of aliased locations > > and the aliasing symlinks are to be installed from a data.tar of a > > binary package such as base-files.
<...> > I think this now comes down to what we as a project care about. Which > use-cases > are important to us? Which properties do we want to preserve? > > What do you think? Essentially, this boils down to risks vs benefits. The risk of going 3c is that every single Debian installation in existence breaks in some interesting ways, as fixing the bootstrapping corner case is delegated to the package upgrade workflow. The sole benefit is that one of the two bootstrapping tools in widespread use keeps its internal code a bit 'cleaner' from the point of view of some technically unnecessary and self-imposed design constraints (yes there's 2 more tools as pointed out yesterday, but they appear to be at least under-maintained judging from tracker.d.o). I don't see how it's worth the risk. This is essentially a problem in the bootstrapping tools, so solving it in the bootstrapping tools is not only the safest approach - worst case scenario, creating a new sid chroot might not work for a couple days, not a big deal given it happens all the time for various reasons as we've seen this week - it's also the right approach. Kind regards, Luca Boccassi
