Hi Didier, While I'm not necessarily disagreeing with the overall point(s) here, some of the points in this list of arguments seem dubious at best. Maybe you could expand?
>* having separate `/` and `/usr` filesystems has been useful in the past for > booting without initramfs onto a minimal root filesystem that carried just > enough to mount the `/usr` filesystem later in the boot process. Given the > evolution of physical hosts' capabilities, initramfs'es have been default in > Debian (and elsewhere) for a long time, and most systems no longer have an > intermediate state during boot in which they have only `/`, but not `/usr`, > mounted. >* another use-case is to be able to share an identical `/usr` over a network > link; hence booting an initramfs, mounting a local `/`, then mounting `/usr` > over the network. It seems that an initramfs with everything needed to mount > a filesystem over a network link directly actually has a smaller footprint. >* booting with `/` only is not systematically tested in Debian anymore; I'm assuming you mean "/ without /usr" here? >* the packaging infrastructure to install files outside of `/usr` is not > standard and represents technical debt: I have no idea what you're suggesting here. >* given its status as remnant "folklore", the distinction between what _needs_ > to be shipped in `/` and what can stay in `/usr` is often interpreted > arbitrarily; >* allowing shipment of identically-named libraries or binaries in different > paths can confuse common understanding of paths precedence. ... >Various valid long-term desireable situations coexist, and while discussing >immediate countermeasures, it is useful to keep the long-term outcome that >those are most likely to produce. > >These are the five possible situations at the time of bullseye (buster + 1): > >* `none`: "merged `/usr`" has been reverted >* `weak`: both directory schemes are allowed, packages only built on classical > hosts >* `middle`: both directory schemes are allowed, packages can be built anywhere >* `hard`: both directory schemes are allowed, packages only built on > "merged `/usr`" hosts >* `all`: only "merged `/usr`" directory schemes are allowed, packages only > built on "merged `/usr`" hosts > >It can be summarized by the following table: > >``` >| | Host types that are allowed | Are merged `/usr` | >Official packages are built on | Packages built on … can break on the other >| >| Codename | classical hosts | merged `/usr` hosts | symlinks allowed | >classical hosts | merged `/usr` hosts | classical hosts | merged `/usr` >hosts | >|----------|-----------------|---------------------|-------------------|—----------------|---------------------|---------------------|----------------------| >| none | yes | no | no | >yes | no | yes | yes | >| weak | yes | yes | yes | >yes | no | no | yes | >| middle | yes | yes | yes | >yes | yes | no | no | >| hard | yes | yes | yes | > no | yes | no | no | >| all | no | yes | yes | > no | yes | yes | no | >``` > >The current state of buster is `weak`. > >=== DRAFT Resolution === > >The Technical Committee resolves to: > >* Option A: Ask the debootstrap maintainers to disable "merged `/usr`" by > default > (Using its §6.1.4 "Overrule a Developer" power; requires a 3:1 majority) > > Given that: > * hosts with both directory schemes already exist, > * the "merged `/usr`" directory scheme ought to be reserved for special > use-cases, > * official packages ought to only be built on classical directory schemes, > > … the Technical Committee considers that the desireable solution at the time > of bullseye is `weak`; and asks the debootstrap maintainers to disable > "merged `/usr`" by default. There is a deeper worry about builds that may be done against the "weak" background. Although buildd chroots are easily fixed up, there's going to be a (small, but unknown) set of maintainers who might be uploading binaries from merged systems. I think we're making good progress on source-only uploads and building in clean chroots etc., but... It's also likely not easy to pick up on "wrong" binary packages built this way. -- Steve McIntyre, Cambridge, UK. st...@einval.com The two hard things in computing: * naming things * cache invalidation * off-by-one errors -- Stig Sandbeck Mathisen
