On 05/01/16 15:55, Ian Jackson wrote: > Abolishing the distinction between /usr and /
This seems to be a somewhat frequent point of confusion so, at the risk of beating a dead horse: "Merged /usr" is not about removing the distinction between /usr and /, it's about removing the distinction between subdirectories of /usr and the corresponding subdirectories of the root, namely /{bin,sbin,lib*}. "lib*" means lib and lib64 in our case, and maybe lib32 (I forget whether we have any architectures where that exists). On distributions that have it, libexec is also in-scope for "merged /usr", but Debian doesn't have libexec anyway. Those subdirectories of the root are the ones that contain static OS-provided files. They have more in common than they have differences: for instance, if you want /usr/bin to be read-only except during upgrades, then you almost certainly also want /usr/lib, /bin and /lib to be read-only except during upgrades. The parts of / that are *not* static OS-provided files and so do not already have an equivalent in /usr (namely /etc, /var, /run, /home, /srv, /opt...) are unaffected, and nobody is proposing /usr/etc or /usr/var or whatever. That would defeat the objective of putting all the static OS-provided files together, by mixing in files that are not static. There are two approaches that have been tried in the past for removing the distinction between /usr/{bin,...} and /{bin,...}, and only one of them is under discussion here; I think everyone agrees the other is a bad idea. The approach Ian seems to be arguing against is the one Debian GNU/Hurd tried to use for a while, where /usr is a symlink to /, and there are real directories /bin, /lib, /share... which contain all the static files. This approach is not good for various reasons, particularly the one Ian pointed out: it becomes difficult to have a read/write /etc but a read-only /{bin,...} because they would naturally live on the same filesystem. This is not being proposed, The approach used in Fedora etc., and in Debian if usrmerge is installed, is to keep /usr a real directory, move all files into it, and make /{bin,sbin,lib*} permanent compatibility symlinks onto /usr. That does not interfere with having a rw / and a ro /usr; indeed, it makes it more effective, because bash, libc6 etc. would also live on /usr and hence be ro. The main (only?) thing that is possible with the traditional concept of split /usr, but *not* possible with merged /usr, is using / as some sort of recovery system, and hoping that / is statistically less likely to be damaged by a hardware or kernel error than /usr because it's so much smaller. However, other factors mean that this is much less useful than it was 10 years ago: * distribution kernels usually (always?) use an initramfs, which is smaller than /, does not need to be rw during normal operation (unlike /), and by definition includes everything necessary to mount / (and as of jessie, /usr), so it makes a somewhat better recovery system than / itself; * on modern storage media, the space requirements for a separate, strictly read-only recovery image like grml are typically insignificant, so there is less need to save space by having / or the initramfs carry out the dual roles of normal boot and abnormal recovery; * because we have traditionally demanded that / contains everything that might conceivably be necessary to mount anyone's /usr, it is actually far from minimal: - full networking, because someone's /usr could be NFS - wpa_supplicant, because you could conceivably mount that NFS directory over wifi or something, if you like juggling chainsaws - disk encryption, because someone's /usr could be encrypted - FUSE, because someone's /usr could be ZFS-on-Linux - libdbus, because someone might be booting with Upstart (or the older systemd versions that used libdbus) - fsck.*, mkfs.* and (u)mount.* helpers for all filesystems, even those that would make no sense for /usr, because the /sbin/mount "API" says they must be in /sbin - bits of Bluetooth support, for some reason that I don't understand I personally think those factors undermine the "/ as recovery" use-case so far that the advantages of a merged /usr far outweigh it. If you disagree, then that's a reason to not install usrmerge (and consider a mandatory merged /usr to be a bad idea, but making merged /usr mandatory is not what's being proposed here). S