## What is "merged `/usr`"
-"Merged `/usr`" describes a possible future standard directories scheme in which the `/{bin,sbin,lib}/` directories have been made superfluous, either through replacing them by symlinks to their `/usr` equivalents (/usr/{bin,sbin,lib}) or by removing them entirely.
+"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.
[0]: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
[1]: https://wiki.debian.org/UsrMerge
+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.
+
## "merged `/usr`" in Debian
In Debian buster, the current testing suite, "merged `/usr`" is only considered for implementation with symlinks (there are no proposals for simply dropping `/{bin,sbin,lib}`) and is implemented in two distinct ways:
At this point, the two variants have to be supported, at least as installation targets of Debian packages.
Two initiatives are worth mentioning at this point:
-* [a patch][https://lists.debian.org/20181202212535.GC11687@gaara.hadrons.org] has been proposed for dpkg-buildpackage to mark packages built on "merged `/usr`" hosts with a `Build-Tainted-By: merged-usr-via-symlinks`;
-* the reproducible builds team has added a "merged `/usr`" variation to their setup, and have then [tagged][https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html] the Debian packages from unstable which had differences due to "merged `/usr`". It seems that ~61 packages were affected by differing builds; 32 from these have been fixed in unstable already.
+* [a patch](https://lists.debian.org/20181202212535.GC11687@gaara.hadrons.org) has been proposed for dpkg-buildpackage to mark packages built on "merged `/usr`" hosts with a `Build-Tainted-By: merged-usr-via-symlinks`;
+* the reproducible builds team has added a "merged `/usr`" variation to their setup, and have then [tagged](https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html) the Debian packages from unstable which had differences due to "merged `/usr`". It seems that ~61 packages were affected by differing builds; 32 from these have been fixed in unstable already.
## The long-term desireable situation
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 three possible situations for the fleet of bullseye (buster + 1) hosts:
-
-* `none`: "merged `/usr`" has been reverted; no bullseye hosts have `/{bin,sbin,lib}/`→ `/usr/{bin,sbin,lib}/` symlinks; only `cat` only exists at `/bin/cat`;
-* `weak`: bullseye hosts can have any of "merged `/usr`" or "classical" directory schemes; official packages are only built on "classical" directory schemes; packages built on "merged `/usr`" are allowed to break on "classical" directory schemes.
-* `hard`: bullseye hosts can have any of "merged `/usr`" or "classical" directory schemes; official packages are built on either "merged `/usr`" or "classical" directory schemes; packages built on either are forbidden to break on either directory schemes.
-* `all`: bullseyes hosts all have "merged `/usr`"; official packages are built on "merged `/usr`"; packages built on "classical" directory schemes are allowed to break on "classical" directory schemes.
+These are the six 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 |
+```
## Immediate actions
projects / debian-ctte.git / blobdiff