On Wed, 05 Dec 2018 at 14:03:19 +0100, Svante Signell wrote: > How about this case: > > - Make as default non merged-/usr for all buildds.
This has been done: I sent patches, which have been applied. (This is actually implemented in two different places, either of which would have been sufficient to make this happen on all official buildds: the Debian sysadmins' script to refresh sbuild chroots explicitly requests unmerged /usr, and debootstrap --variant=buildd also defaults to unmerged /usr.) > - Make a choice of non merged-/usr or merged-/usr in the installer. If you mean "the installer maintainers make a choice": this is effectively what we have now. The debian-installer maintainers are the maintainers of debootstrap, they have chosen to merge /usr in new installations, and this bug report is a request for the technical committee to decide whether to overrule them. If you mean "users who run the installer are asked whether they want merged or unmerged /usr": this seems worse than either merged /usr or unmerged /usr, because it's asking new Debian users to make a choice in which they likely have no way to know which answer is most appropriate, because they aren't using Debian yet. If even experienced Debian users disagree over what the answer should be (which we do, as you can see in this thread), then we should not expect new users to be able to make an informed decision. > - Users wanting merged-/usr install the usrmerge package and convert to > merged- > /usr. This is one of several ways to achieve that result: either install usrmerge, or install into a sysroot that already contains symlinks /lib -> /usr/lib etc., or use debootstrap --merged-usr (or a recent debootstrap version in which merged /usr is the default for recent suites), or do the equivalent of usrmerge by hand. Merging /usr on an existing system isn't actually difficult to implement if you are manipulating the system from the outside: the hard parts of the task of the usrmerge package are making it work on a running system, and avoiding the system being left in a broken state if the transition to merged /usr is left half-complete. An alternative to the usrmerge package might be to do this transition in an initramfs hook or something similar, which would guarantee that nothing else is concurrently altering /usr or the directories that are meant to be merged into it. > 2) For those having merged-/usr installed: > Re-run usrmerge to convert all newly installed packages to merged-/usr. > Is this possible or is installing that package a install-once-only? If you already have the merged-/usr filesystem layout (either by installing usrmerge, by using debootstrap with --merged-usr, or by creating the symlinks some other way), then all newly installed packages effectively already behave as though they had been converted to merged /usr: dpkg sees that the .deb contains a file like /bin/sed, but the root filesystem contains a symlink /bin -> /usr/bin, so it dereferences the symlink and unpacks sed into /usr/bin. This is part of dpkg's more general support for relocating directories elsewhere by replacing them with a symlink. If that wasn't true, then the usrmerge package would not have been feasible to implement. It would clearly have been unacceptable to make it impossible to install unmodified packages later. This remains true even if the usrmerge package is subsequently removed, if it was ever installed. The symlinks /bin, /sbin, /lib* remain present, because removing them would break the system: paths like /bin/sh, /sbin/fsck, /lib/ld-linux.so.2 and /lib64/ld-linux-x86-64.so.2 must continue to work indefinitely (even if the files are physically located at /usr/bin/sh, /usr/sbin/fsck and so on). smcv