]> git.donarmstrong.com Git - debian-ctte.git/blobdiff - 914897_merged_usr/ballot.md
Step forward with an advice offer proposal
[debian-ctte.git] / 914897_merged_usr / ballot.md
index 949b2f40e6b1a1fec6c3b0ffc7885290213a8e9f..3f03916cd7947658213df6dc82a064a617f3eadc 100644 (file)
@@ -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 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.
@@ -17,7 +17,7 @@ The motivation to get Debian systems to converge towards such a scheme is vastly
 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).
+* `/{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
@@ -26,12 +26,14 @@ The compatibility symbolic links `/lib` → `/usr/lib` and `/lib64` → `/usr/li
 
 ## "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:
+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 main 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.
+* new hosts get the `/{bin,sbin,lib*}/`→ `/usr/{bin,sbin,lib*}/` symlinks by default when using debootstrap >= 1.0.102.
 
-The usrmerge package contains a `/usr/lib/convert-usrmerge` perl executable that runs in `postinst`, that will move the contents of `/{bin,sbin,lib}/` and replace these directories with symlinks when empty.
+The usrmerge package contains a `/usr/lib/convert-usrmerge` perl executable that runs in `postinst`, that will move the contents of `/{bin,sbin,lib*}/` and replace these directories with symlinks when empty.
+
+It is also possible to merge `/usr` in other ways, for example with `debootstrap --merged-usr` or by bootstrapping into a chroot that already contains the necessary symlinks.
 
 [2]: https://tracker.debian.org/pkg/usrmerge
 
@@ -54,7 +56,7 @@ Two initiatives are worth mentioning at this point:
 
 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 six possible situations at the time of bullseye (buster + 1):
+These are the five 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
@@ -75,18 +77,18 @@ It can be summarized by the following table:
 |      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`", let users who ran `usrmerge` on their own
-* 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).
-
-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`".
+The current state of buster is `weak`.
+
+== TO BE DISCUSSED
+== ## Offering Advice §6.1.5
+== 
+== 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`.
+== TO BE DISCUSSED
 
 ## For buster