# #914897: tech-ctte: Should debootstrap disable merged `/usr` by default?
-=== DRAFT Resolution ===
-
## What is "merged `/usr`"
-"Merged `/usr`" describes a possible future standard directories scheme in which the `/{bin,sbin,lib*}/` directories have been made superfluous through replacing them by symlinks to their `/usr` equivalents (/usr/{bin,sbin,lib*}).
+"Merged `/usr`" describes a possible future standard directories scheme in which the `/{bin,sbin,lib*}/` directories have been made superfluous through replacing them by symlinks to their `/usr` equivalents (`/usr/{bin,sbin,lib*}`).
The motivation to get Debian systems to converge towards such a scheme is vastly documented elsewhere ([FDO's TheCaseForTheUsrMerge][0], [wiki.d.o UsrMerge][1]) but can be summarized as the following points:
-* 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.
+* 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. Booting hosts through that intermediate state is not systematically tested in Debian anymore.
* 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;
* the packaging infrastructure to install files outside of `/usr` is not standard and represents technical debt:
* 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.
The arguments against moving the base directories' scheme towards "merged `/usr`" are as follows:
* there's no gain in disrupting something that is not inherently broken;
-* `/{bin,sbin,lib*}/` → `/usr/{bin,sbin,lib*}/` symlinks create confusing views of the system (`/bin/cat` and `/usr/bin/cat` are the same file), and dpkg doesn't support this situation cleanly [#134758](https://bugs.debian.org/134758).
+* `/{bin,sbin,lib*}/` → `/usr/{bin,sbin,lib*}/` symlinks create confusing views of the system (`/bin/cat` and `/usr/bin/cat` are the same file), and dpkg doesn't support this situation cleanly: [#134758](https://bugs.debian.org/134758).
+* it is possible for distributions to converge towards having all system files in `/usr` in finite time instead of shortcutting this migration with `/{bin,sbin,lib*}/` → `/usr/{bin,sbin,lib*}/` symlinks.
[0]: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
[1]: https://wiki.debian.org/UsrMerge
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 |
+| | 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`.
-== TO BE DISCUSSED
-== ## Offering Advice §6.1.5
-==
-== Given that:
-== * hosts with both directory schemes already exist,
-== * it seems unpractical to allow official packages to be built on either directory schemes,
-== * there's inherent value in the simplicity of "merged `/usr`" directory schemes,
-==
-== the Technical Committee considers that the desireable solution at the time of bullseye is `hard`.
-== TO BE DISCUSSED
+=== DRAFT Resolution ===
-## For buster
+The Technical Committee resolves to:
-Anyway:
- Recommend tainting binary packages built on "merged-`/usr`" hosts, and warning at install time.
- Recommend tackling "merged-`/usr`" properly over bullseye (buster+1)
+* 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)
-Option A:
- Override debootstrap maintainers; let new hosts be identical to buildds, non-"merged-`/usr`".
+ 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,
-Option B:
- Do not override debootstrap maintainers
- Encourage finding ways quickly to reconcile buildds' setups with user setups.
+ … 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.
+* Option B: Decline to override the debootstrap maintainers; offer advice
+ (Using its §6.1.5 "Offering advice" power)
-=== End DRAFT Resolution ===
+ Given that:
+ * hosts with both directory schemes already exist,
+ * it seems unpractical to allow official packages to be built on either directory schemes,
+ * there's inherent value in the simplicity of "merged `/usr`" directory schemes,
+
+ … the Technical Committee considers that the desireable solution at the time of bullseye is `hard`; and declines to override the debootstrap maintainers.
+=== End DRAFT Resolution ===