Re: support for merged /usr in Debian
On 05/01/16 09:49, Paul Wise wrote:
> On Mon, Jan 4, 2016 at 2:14 AM, Russ Allbery wrote:
>
>> And yet, it works, and it means that we don't have to try to harass a
>> thousand package maintainers into doing essentially untestable busy-work
>> to try to move things around between /usr, /bin, and /lib to support a
>> tiny handful of systems for which other approaches are available.
>
> The bin-or-sbin-binary-requires-usr-lib-library tag in adequate tests this.
> piuparts runs adequate for every single package in Debian.
Yes, this finds a bunch of the simpler cases where the assumption that /
must be self-contained is not met. More complex cases, like udev rules
that reference executables or data files (PCI IDs, etc.) in /usr, are
not found (and I suspect that finding all of them would require solving
the Halting Problem).
However, I think the results of only considering shared library linking
are already sufficient to demonstrate the structural problems with
requiring a self-contained rootfs that is distinct from /usr:
* people want to be able to boot with / but not /usr, in the hope that
the "minimal" / is so much smaller than /usr that it is statistically
less likely to be damaged;
* but we are assuming that / contains everything that might conceivably
be needed to mount anyone's /usr, including pathological cases like
ZFS via FUSE, or NFS-over-wifi;
* so / ends up absorbing large pieces of what probably ought to be /usr
Over time, a system where / is required to be self-contained, and the
functionality and requirements of programs in / increase, is going to
get an ever-increasing amount of stuff in /. Increasing how much is in /
defeats the idea of its use as a minimal recovery system, and brings us
closer to the model that Debian GNU/Hurd tried to use (unifying
/usr/bin, etc., with /bin, etc., by making /usr a symlink to /).
If moving everything to / was a good idea, the Hurd maintainers would
have continued to do it, and the upstreams who advocate the "/usr merge"
on Linux would probably have done that too. Indeed, both groups
considered that option, but both groups rejected it. Ian Jackson pointed
out one of the major reasons to reject doing it that way round,
elsewhere in the thread: if /bin and /etc are on the same filesystem,
you can't have a read-only /bin and a read/write /etc at the same time.
The structure used in usrmerge (and in Fedora, etc.), where the real
files end up in /usr, *does* work as desired for that
read-only/read-write split.
----
Looking at the adequate logs:
udisks2: bin-or-sbin-binary-requires-usr-lib-library
/sbin/umount.udisks2 => /usr/lib/x86_64-linux-gnu/libudisks2.so.0
umount.udisks2 is in /sbin because the umount-helper "API" says umount
helpers are always /sbin/umount.foo. It cannot possibly be useful until
the actual udisks2 daemon, which is on /usr, is running, because until
that happens, nothing is going to mount a filesystem that is marked to
be unmounted using umount.udisks2. Are you saying that, because this
helper exists, libudisks2, libgobject, libgio, libffi should all move
from /usr to /?
0m24.5s DEBUG: Starting command: ['adequate', '--root',
'/srv/piuparts.debian.org/tmp/tmpk5ZNdX', 'iputils-ping']
0m24.6s DUMP:
iputils-ping: bin-or-sbin-binary-requires-usr-lib-library /bin/ping6
=> /usr/lib/x86_64-linux-gnu/libgnutls-openssl.so.27
I don't know why a ping implementation wants to do SSL, but let's assume
that's a useful thing to do for some reason. Are you saying that GNUTLS
and all its dependencies should move from /usr to /?
0m23.3s DEBUG: Starting command: ['adequate', '--root',
'/srv/piuparts.debian.org/tmp/tmpSxf5ep', 'gdisk']
0m23.4s DUMP:
gdisk: bin-or-sbin-binary-requires-usr-lib-library /sbin/cgdisk =>
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
If we believe the "/ as recovery system" meme, it seems reasonable that
the various flavours of fdisk should be on the root filesystem. Are you
saying that, because there is a fdisk implementation written in C++,
libstdc++6 should move from /usr to /?
rpcbind: bin-or-sbin-binary-requires-usr-lib-library /sbin/rpcbind =>
/usr/lib/x86_64-linux-gnu/libkrb5.so.3
rpcbind is on the root filesystem because (/usr or) /var might
conceivably be NFS-mounted. Presumably it's linked to Kerberos libraries
because they provide useful functionality, rather than just for fun. Are
you saying that Kerberos libraries should move from /usr to /?
(And continue through the list, I'm sure you get the idea - if we go
through all of these and apply the historical policy, then calling the
root filesystem "minimal" seems like even more of a stretch.)
S
Reply to: