From b32d33c5fa8cb24522ea44315104f2958fac10d2 Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Mon, 4 Feb 2019 14:44:13 +0000 Subject: [PATCH] merged usr: Remove `full` from consideration Platform ABIs require /lib and /lib64 to exist, and widespread assumptions require /bin and /sbin, so there's little point in trying to remove them altogether. I am not aware of any distributions that have considered removing the symlinks, even those where merged /usr was a mandatory flag-day transition. Acked by OdyX on IRC. --- 914897_merged_usr/ballot.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/914897_merged_usr/ballot.md b/914897_merged_usr/ballot.md index 6f63671..949b2f4 100644 --- a/914897_merged_usr/ballot.md +++ b/914897_merged_usr/ballot.md @@ -4,7 +4,7 @@ ## 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. @@ -22,6 +22,8 @@ The arguments against moving the base directories' scheme towards "merged `/usr` [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: @@ -59,7 +61,6 @@ These are the six possible situations at the time of bullseye (buster + 1): * `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 -* `full`: only "merged `/usr`" directory schemes are allowed, symlinks have been removed It can be summarized by the following table: @@ -72,7 +73,6 @@ It can be summarized by the following table: | middle | yes | yes | yes | yes | yes | no | no | | hard | yes | yes | yes | no | yes | no | no | | all | no | yes | yes | no | yes | yes | no | -| full | no | yes | no | no | yes | yes | yes | ``` ## Immediate actions -- 2.39.2