On Thu, 29 Jun 2023 at 13:34, Helmut Grohne <hel...@subdivi.de> wrote: > > 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?
The risk to unstable is not just to become unbootstrappable, but completely broken, for every installation, because of the required song&dance with the essential set in order to allow for base-files to ship symlinks, that needs to happen perfectly and flawlessly, everywhere, always, for all times. And not just in unstable, but for all upgrades from bookworm to trixie too, as they'll have to perform the same song&dance too. This is way worse than the usrmerge package transition: at least there we can do some pre-flight checks, and abort if unworkable conditions are found, without touching anything. As far as I can see such a failsafe just isn't there with this approach. The opposite side of the coin is that unstable (and only unstable) new chroots cannot be created for a day or two. It seems to me the category and magnitude of risk of these two options are not even remotely comparable. > 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"? The difference is that what you are mentioning here is just broken and unworkable, it's not just "maintenance cost", although that's a factor. On the other hand having a bootstrap protocol is not broken, it's how things work and how they will always work. How much work said protocol needs to do is a design choice, and opinions differ, but neither of the two options can be categorized as outright broken. > > 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. I haven't missed anything, I just think it is way more important to focus on finishing the internal part of the transition and thus lift the moratorium than to philosophize on first principles. However, if you want to go there, the only reason we have the usrmerge package is that we need to support updating existing installations but it is also impossible for anybody in the project, even the CTTE, to get anything changed inside dpkg, so a workaround had to be found. I'd personally be happy to see the package removed from trixie, given the transition for existing systems is done and we don't support skip-upgrades, and it has served its purpose. Kind regards, Luca Boccassi
