Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib
On Wed, 19 Feb 2020 at 06:26:32 +0100, Marco d'Itri wrote:
> Creating symlinks in /bin and /sbin DOES NOT result in a merged-/usr
> system, because the content of /usr would not be decoupled anymore from
> the content of /.
> A merged-/usr system must have /bin /sbin /lib* symlinks to /usr.
That's what I would say, too. For me, the major properties of merged /usr
are:
* After it has been merged, it makes no difference whether a path was
traditionally on the rootfs, in /usr, in both via symlinks, or some
mixture of those depending on distribution/release, because now it
definitely exists in both places
* If /usr is mounted separately, then the root filesystem contains only
configuration (/etc), local state (/var, /home, /srv and so on),
and a small number of compat symlinks of the form foo -> usr/foo
(which could be deployed statelessly by boot-time infrastructure like
the initramfs or a container manager, rather than being seen as part
of the OS installation)
If /bin and /sbin are directories containing symlink farms, then we
don't have the second of those properties, because the contents of those
directories depend on the specific software that is installed in /usr
(for example there shouldn't be a /bin/plymouth -> usr/bin/plymouth
symlink if plymouth isn't installed).
For an example that is not (usually!) Debian and doesn't involve a
traditional package manager: Flatpak runtimes contain only a merged /usr
(more precisely, the runtime is a libostree commit containing a file
./metadata, which is not directly part of the filesystem, and a directory
./files/, which gets mounted on /usr). The root filesystem is a tmpfs, in
which the Flatpak container-runner creates a minimal /etc and the /bin,
/sbin, /lib* symlinks. When doing that, the Flatpak container-runner
doesn't know, or need to know, whether the runtime is based on Debian,
Fedora, the freedesktop.org SDK, or something else: all it needs to know
is that the runtime needs to end up as the container's /usr.
Mostly for historical reasons, Docker is designed in terms of complete
sysroot tarballs rather than in terms of a /usr tarball, but I could
easily imagine a whole-system container or virtualization platform (or
an alternate-universe version of Docker) in which the container image
(template for containers) representing an OS installation is just a copy
of a merged-/usr.
> What you are proposing is NOT an alternative implementation of
> merged-/usr but something else, which has no significant benefits.
I think that's somewhat overstating it: what Guillem is proposing
has a small subset of the benefits of merged /usr. *For the paths that have
explicitly been migrated*, like [/usr]/bin/plymouth and
[/usr]/sbin/iptables, it doesn't matter any more which path you use.
(Perhaps you consider that to be too small a subset to be significant.)
However, for paths that have not been migrated in this way (for example
/usr/bin/dbus-send, which has never been in /bin on Debian, although it
was in /bin for a while on Ubuntu), it still does matter which path is
used: /bin/dbus-send exists on Fedora and some Ubuntu releases, but not
on Debian, unless something like usrmerge is used on the Debian system.
I agree that what Guillem is proposing also does not have the property,
which I think is one that is important to you?, that the contents of the
root directory are decoupled from /usr (can be set up by an initramfs
or a container-runner, perhaps in a tmpfs, without detailed knowledge
of the OS installation in /usr).
smcv
Reply to: