Fix typo between empty and weak

[debian-ctte.git] / 914897_merged_usr / ballot.md

diff --git a/914897_merged_usr/ballot.md b/914897_merged_usr/ballot.md
index 9c364d1930742858de22d10fa2c7864f61790242..661a66e3f4df72485dc59bd1b0b80a1d83e4ff75 100644 (file)
--- a/914897_merged_usr/ballot.md
+++ b/914897_merged_usr/ballot.md
@@ -5,20 +5,20 @@
 "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:
 
 "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.
 
 * 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;
 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.
 
 
 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.
 


@@ -39,24 +39,25 @@ It is also possible to merge `/usr` in other ways, for example with `debootstrap
 
 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).
 
 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.
+Some such differences can actually render the built packages unusable 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.
 
 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 hosts with such directory schemes can _potentially_ be broken on non-"merged `/usr`" systems.
+The lesson here is that with the existence of (any of) the usrmerge and the debootstrap default change, "merged `/usr`" Debian systems exist already, and that packages built on hosts with such directory schemes can _potentially_ be broken on non-"merged `/usr`" systems.

 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.
 
 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.
 

-## The long-term desireable situation
+## The long-term desirable 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.
+Various valid long-term desirable 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 five possible situations at the time of bullseye (buster + 1):
+These are the six possible situations at the time of bullseye (buster + 1):

 
 * `none`: "merged `/usr`" has been reverted
 
 * `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
 * `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


@@ -69,7 +70,8 @@ It can be summarized by the following table:
 | 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         |
 | 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         |
+|    empty |       yes       |          no         |         no        |       yes       |          no         |         yes         |          yes         |
+|     weak |       yes       |         yes         |        yes        |       yes       |          no         |          no         |           no         |

 |   middle |       yes       |         yes         |        yes        |       yes       |         yes         |          no         |           no         |
 |     hard |       yes       |         yes         |        yes        |        no       |         yes         |          no         |           no         |
 |      all |       no        |         yes         |        yes        |        no       |         yes         |         yes         |           no         |
 |   middle |       yes       |         yes         |        yes        |       yes       |         yes         |          no         |           no         |
 |     hard |       yes       |         yes         |        yes        |        no       |         yes         |          no         |           no         |
 |      all |       no        |         yes         |        yes        |        no       |         yes         |         yes         |           no         |


@@ -79,26 +81,14 @@ The current state of buster is `weak`.
 
 === DRAFT Resolution ===
 
 
 === DRAFT Resolution ===
 

-The Technical Committee resolves to:
-
-* Option A: Ask the debootstrap maintainers to disable "merged `/usr`" by default
-  (Using its §6.1.4 "Overrule a Developer" power; requires a 3:1 majority)
+The Technical Committee resolves to decline to override the debootstrap maintainers.

 
 

-  Given that:
-  * hosts with both directory schemes already exist,
-  * the "merged `/usr`" directory scheme ought to be reserved for special use-cases,
-  * official packages ought to only be built on classical directory schemes,
+Furthermore, using its §6.1.5 "Offering advice" power, the Technical Committee considers that:

 
 

-  … the Technical Committee considers that the desireable solution at the time of bullseye is `weak`; and asks the debootstrap maintainers to disable "merged `/usr`" by default.
+* A: The desirable 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: Decline to override the debootstrap maintainers; offer advice
-  (Using its §6.1.5 "Offering advice" power)
+* B: The desirable 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.

 
 

-  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`; and declines to override the debootstrap maintainers.
+* FD: Further Discussion

 
 === End DRAFT Resolution ===
 
 === End DRAFT Resolution ===