-# #914897: tech-ctte: Should debootstrap disable merged /usr by default?
+# #914897: tech-ctte: Should debootstrap disable merged `/usr` by default?
=== DRAFT Resolution ===
-"Merged /usr" describes a possible future standard directories scheme in which the /{bin,sbin,lib}/ directories have been made superfluous, either through making these symlinks to their /usr equivalents (/usr/{bin,sbin,lib}) or by removing them entirely.
-The motivation to get Debian systems to converge towards such a scheme is vastly documented elsewhere [0,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 don't have an intermediate state during boot in which they have only / , but not /usr mounted 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; an initramfs with everything needed to mount a filesystem over a network link is actually a smaller
- * booting with / only is not systematically tested in Debian;
- * 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.
+"Merged `/usr`" describes a possible future standard directories scheme in which the `/{bin,sbin,lib}/` directories have been made superfluous, either through making these symlinks to their `/usr` equivalents (/usr/{bin,sbin,lib}) or by removing them entirely.
+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:
-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].
+* 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 don't have an intermediate state during boot in which they have only `/`, but not `/usr` mounted 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; an initramfs with everything needed to mount a filesystem over a network link is actually a smaller
+* booting with `/` only is not systematically tested in Debian;
+* 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.
-[0] https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
-[1] https://wiki.debian.org/UsrMerge
-[#134758] https://bugs.debian.org/134758
+The arguments against moving the base directories' scheme towards "merged `/usr`" are as follows:
-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:
- * existing hosts can be made to have a "merged /usr" by installing the usrmerge [2] package;
- * new hosts get the /{bin,sbin,lib}/→ /usr/{bin,sbin,lib}/ symlinks by default when using debootstrap >= 1.0.102.
+* 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].
-The usrmerge package contains a /usr/lib/convert-usrmerge perl executable that runs in postinst, will move the contents of /{bin,sbin,lib}/ and replace these directories with symlinks when empty.
+[0]: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
+[1]: https://wiki.debian.org/UsrMerge
-[2] https://tracker.debian.org/pkg/usrmerge
+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:
-Since the default change in debootstrap 1.0.102, some issues have arisen. Due to the fact that some buster/sid hosts have the "merged /usr" symlinks in place, it has been observed that some binary packages carried some traces of these differences (notably official packages built on Debian buildd hosts which had been resetup). Some such differences can actually render the built packages unuseable on non-"merged /usr" systems. For example, if `cat` is detected at build-time in /usr/bin/cat (where coreutils ships /bin/cat), a binary hardcoding that path will try to use /usr/bin/cat after installation, but that path doesn't exist in non-"merged /usr" systems. In order to mitigate this, debootstrap has been modified to let its "buildd" variant be non-"merged /usr", the Debian buildds have been resetup and the affected packages rebuilt.
+* existing hosts can be made to have a "merged `/usr`" by installing the [usrmerge][2] package;
+* new hosts get the `/{bin,sbin,lib}/`→ `/usr/{bin,sbin,lib}/` symlinks by default when using debootstrap >= 1.0.102.
-The lesson here is that with the existance of (any of) the usrmerge and the debootstrap default change, "merged /usr" Debian systems exist already, and that packages built on such directory schemes
+The usrmerge package contains a `/usr/lib/convert-usrmerge` perl executable that runs in `postinst`, will move the contents of `/{bin,sbin,lib}/` and replace these directories with symlinks when empty.
+
+[2]: https://tracker.debian.org/pkg/usrmerge
+
+Since the default change in debootstrap 1.0.102, some issues have arisen. Due to the fact that some buster/sid hosts have the "merged `/usr`" symlinks in place, it has been observed that some binary packages carried some traces of these differences (notably official packages built on Debian buildd hosts which had been resetup). Some such differences can actually render the built packages unuseable on non-"merged `/usr`" systems. For example, if `cat` is detected at build-time in `/usr/bin/cat` (where coreutils ships `/bin/cat`), a binary hardcoding that path will try to use `/usr/bin/cat` after installation, but that path doesn't exist in non-"merged `/usr`" systems. In order to mitigate this, debootstrap has been modified to let its "buildd" variant be non-"merged `/usr`", the Debian buildds have been resetup and the affected packages rebuilt.
+
+The lesson here is that with the existance of (any of) the usrmerge and the debootstrap default change, "merged `/usr`" Debian systems exist already, and that packages built on such directory schemes
## Describe what is the desired situation
projects / debian-ctte.git / commitdiff