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