Some changes to the usrmerge ballot draft

diff --git a/914897_merged_usr/ballot.md b/914897_merged_usr/ballot.md
index 90a9411083aed793ad5ded750390d62e69df69a8..e133da11f31285f6e467a467a29a21d44b6a32de 100644 (file)
--- a/914897_merged_usr/ballot.md
+++ b/914897_merged_usr/ballot.md
@@ -4,12 +4,12 @@
 
 ## 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 making these 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, either through replacing them by 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:
 
-* 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;
+* 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; an initramfs with everything needed to mount a filesystem over a network link is actually a smaller *[A smaller what? -GW]*
+* 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:
 * 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.
@@ -29,7 +29,7 @@ In Debian buster, the current testing suite, "merged `/usr`" is only considered
 * 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 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.
+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.
 
 [2]: https://tracker.debian.org/pkg/usrmerge
 
@@ -48,12 +48,12 @@ Two initiatives are worth mentioning at this point:
 TODO: prose the ideas below, I haven't had enough time.
 
 Given that hosts with different top-level directory schemes already exist; there are various ways forward.
-* flag-day to get all hosts on "merged `/usr`", trough 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).
+* 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 repro build tests, it does not seem impossible to enforce that official Debian packages support being built on either "merged `/usr`" or non-"merged `/usr`" systems.
+Given the repro build tests, 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 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`".