"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.
-* 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:
+* 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 share system files from `/usr` between hosts (over a network link) or containers (locally) which use different data or configuration. Having all software under `/usr` (instead of spread between `/` and `/usr`) makes the centralized update and the sharing easier.
+* the packaging infrastructure to install files outside of `/usr` (e.g. installing libs under `/lib` instead of `/usr/lib`) 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.
+[0]: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
+[1]: https://wiki.debian.org/UsrMerge
+
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).
-
-[0]: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
-[1]: https://wiki.debian.org/UsrMerge
+* `/{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.
The compatibility symbolic links `/lib` → `/usr/lib` and `/lib64` → `/usr/lib64` are required by the various CPUs' platform ABIs (for example i386 requires `/lib/ld-linux.so.2` to resolve to glibc's `ld.so`, and amd64 requires `/lib64/ld-linux-x86-64.so.2`) so there are no plans to remove them altogether. Similarly, removing `/bin` is not under consideration because it would break the assumption that `/bin/sh` exists, and removing `/sbin` would break the assumption that `/sbin/fsck.*` and `/sbin/mount.*` exist.
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):
+These are the six possible situations at the time of bullseye (buster + 1):
* `none`: "merged `/usr`" has been reverted
+* `empty`: "merged `/usr`" has been reverted, `/usr` is empty (but the mandatory files)
* `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
| 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 |
+| empty | yes | no | no | yes | no | yes | no |
| weak | yes | yes | yes | yes | no | no | yes |
| middle | yes | yes | yes | yes | yes | no | no |
| hard | yes | yes | yes | no | yes | no | no |
=== 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)
+The Technical Committee resolves to decline to override the debootstrap maintainers.
- 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,
+Furthermore, using its §6.1.5 "Offering advice" power, the Technical Committee considers that:
- … 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.
+* A: The desireable solution at the time of bullseye is `weak`; both directory schemes should be allowed, but packages should only be built on hosts with classical directory schemes (or chroots).
-* Option B: Decline to override the debootstrap maintainers; offer advice
- (Using its §6.1.5 "Offering advice" power)
+* B: The desireable solution at the time of bullseye is `hard`; both directory schemes should be allowed, and packages can be built on hosts with either classical or "merged-`/usr`" directory schemes.
- 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.
+* FD: Further Discussion
=== End DRAFT Resolution ===
projects / debian-ctte.git / blobdiff