Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?
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
Reply to: