# #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.
-* 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.
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
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 |
+| 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 |
+| all | no | yes | yes | no | yes | yes | no |
```
-## Immediate actions
-
-Given that hosts with different top-level directory schemes already exist; there are various ways forward that would allow for Debian to converge to a desireable situation:
-
-* Flag-day to get all hosts on "merged `/usr`", through a base-files version; probably in buster+1 (bullseye)
-* Disallow "merged `/usr`", leave users who already have merged `/usr` in an unsupported situation
-* Let Debian converge to a situation where non-"merged `/usr`" Debian hosts are equivalent to symlinked "merged `/usr`" hosts; do this through upgrading all packages shipping files outside of /usr (but exceptions) to stop doing this. Could be achieved by setting policy for buster+1 (should) and buster+2 (must), or maybe even shorter. This would make the symlink "shortcut" migration redundant.
-* Support both "merged `/usr`" and non-"merged `/usr`" systems forever: this implies that our packaging tools need to either support countering effects of "merged `/usr`" (e.g. through manipulating PATH for builds to detect files only in their .deb paths) or identifying tainted packages, and letting installing users decide (warn or error out at install time).
+The current state of buster is `weak`.
-Given the tests from the reproducible builds' initiative, it does not seem impossible to enforce that official Debian packages support being built on either "merged `/usr`" or non-"merged `/usr`" systems; however, due to Debian being upstream to many other distributions, and due to `.deb` packages (which often don't go through the same level of checking and policing as official Debian's) being built by Independent Software Vendors (ISVs), our users will probably face similar problems to what we have described.
-
-It's bizarre to have official buildds be non-"merged `/usr`" while user hosts will converge to be more and more "merged `/usr`".
+=== DRAFT Resolution ===
-## For buster
+The Technical Committee resolves to decline to override the debootstrap maintainers.
-Anyway:
- Recommend tainting binary packages built on "merged-`/usr`" hosts, and warning at install time.
- Recommend tackling "merged-`/usr`" properly over bullseye (buster+1)
+Furthermore, using its §6.1.5 "Offering advice" power, the Technical Committee considers that:
-Option A:
- Override debootstrap maintainers; let new hosts be identical to buildds, non-"merged-`/usr`".
+* 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:
- Do not override debootstrap maintainers
- Encourage finding ways quickly to reconcile buildds' setups with user setups.
+* 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.
+* FD: Further Discussion
=== End DRAFT Resolution ===
-
projects / debian-ctte.git / blobdiff