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