Re: Second take at DEP17 - consensus call on /usr-merge matters
Hi Luca,
On Thu, Jun 29, 2023 at 12:49:16PM +0100, Luca Boccassi wrote:
> 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'm not sure you understand what 3c is about. I think it is safe to say
that you are in favour of moving all of the files to their canonical
location (i.e. from / to /usr). This is half of the picture for 3c. The
other half is shipping the symbolic links in base-files rather than
having them created in some way not tracked by dpkg. If you plug these
two together, you have made /usr-merged bootstrapping work without
having changed the protocol.
So what is the risk involved here? I think there are three main risk
categories at play:
1. The risk of effects from moving files from / to /usr. This is a risk
that you clearly see as worth taking regardless of the bootstrap
case.
2. The risk of effects from shipping the symbolic links in base-files. I
see that you'd rather not do this, but not shipping them in any
package poses a deletion risk of its own, so shipping them
effectively is a risk mitigation and is what allows us to drop
protective diversions eventually. It stills risks breaking
debootstrap's behind-the-back approach of merging, so we'll likely
have to do a stable upload of debootstrap.
3. The risk of unstable becoming temporarily non-bootstrappable. This is
where I see the main fragility of the approach. As is evident from
your next paragraph, you don't really care about this either.
Given this, it seems rather evident that you have a different risk in
mind that I do not see at this time. Can you elaborate?
Then, software maintainers tend to say "no" when a feature poses a
non-trivial cost to permanent maintenance. We see this all the time and
you shrug it off, because it's not your package. However, when people do
the reverse (e.g. diverting systemd's units poses a non-trivial
maintenance cost to systemd), you take it for granted that you can
unilaterally say "no". Why is it ok for you to say "no", but not for
other maintainers to say "no"?
> 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.
You seem to have missed Johannes reasoning entirely. He sees Debian as a
component-based system. He argues that this is not a problem in the
bootstrapping tools, but a problem in the components being bootstrapped.
In effect, the usrmerge binary package currently implements it in a
component-oriented way. Since it is a problem with that component,
solving it there makes most sense, no? That alone makes it obvious, that
this is not a problem limited to bootstrapping. We have now duplicated
this mechanism to usrmerge and debootstrap and you are proposing to
duplicate it again. I argue that a maintainable implementation should
centralize this aspect into (preferably only) one component.
Helmut
Reply to: