Larger section on desireable long-term situations

diff --git a/914897_merged_usr/ballot.md b/914897_merged_usr/ballot.md
index df1a85a612ee269c153b165ba4d454e820aa8b75..4ce32e2213cbec85c2302ab8f5dce4548f5ba23a 100644 (file)
--- a/914897_merged_usr/ballot.md
+++ b/914897_merged_usr/ballot.md
@@ -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
@@ -35,9 +35,14 @@ The usrmerge package contains a `/usr/lib/convert-usrmerge` perl executable that
 
 ## Issues from "merged `/usr`"
 
-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.
+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 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. The fact that packages built on "merged `/usr`" systems are
+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.
+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`;
@@ -45,15 +50,25 @@ Two initiatives are worth mentioning at this point:
 
 ## The long-term desireable situation
 
-TODO: prose the ideas below, I haven't had enough time.
+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 three possible situations for the fleet of bullseye (buster + 1) hosts:
+
+* `none`: "merged `/usr`" has been reverted; no bullseye hosts have `/{bin,sbin,lib}/`→ `/usr/{bin,sbin,lib}/` symlinks; only `cat` only exists at `/bin/cat`;
+* `weak`: bullseye hosts can have any of "merged `/usr`" or "classical" directory schemes; official packages are only built on "classical" directory schemes; packages built on "merged `/usr`" are allowed to break on "classical" directory schemes.
+* `hard`: bullseye hosts can have any of "merged `/usr`" or "classical" directory schemes; official packages are built on either "merged `/usr`" or "classical" directory schemes; packages built on either are forbidden to break on either directory schemes.
+* `all`: bullseyes hosts all have "merged `/usr`"; official packages are built on "merged `/usr`"; packages built on "classical" directory schemes are allowed to break on "classical" directory schemes.
+
+## 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:
 
-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`", 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; 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.
+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`".