Re: Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?
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. steve@einval.com
The two hard things in computing:
* naming things
* cache invalidation
* off-by-one errors -- Stig Sandbeck Mathisen
Reply to: