Re: Second take at DEP17 - consensus call on /usr-merge matters
On Thu, 29 Jun 2023 at 11:53, Johannes Schauer Marin Rodrigues
<josch@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
Reply to: