On Tue, 18 Feb 2020 at 12:44:18 +0100, Marco d'Itri wrote: > On Feb 16, Simon McVittie <s...@debian.org> wrote: > > I think we have consensus that consolidating all static OS files into /usr > > (removing the distinction between /usr and the static parts of the root > > filesystem) is the route that Debian is taking. I think we do not have > > consensus on how that is to be achieved. > > Is everybody persuaded now that there is > no point in continuing to support non-merged systems?
No. Sorry, I phrased that badly. The consensus that I think we have is: we are no longer attempting to support systems booting without /usr mounted, and therefore it is not a bug if programs and libraries on the rootfs have dependencies in /usr. (That's a less strong guarantee than the one you are probably hoping for.) That means that libraries and executables whose paths are not hard-coded anywhere are allowed to migrate from the root filesystem to /usr (modulo warnings about possible bugs: see elsewhere in this thread). However, it doesn't give us a solution for what should happen to things that are canonically on the root filesystem and *do* have their absolute paths hard-coded somewhere, most critically /lib*/ld*.so.* and /bin/sh. One of those mechanisms to consolidate files into /usr is to redirect files en masse "behind dpkg's back", making use of dpkg's support for unpacking through symlinks-to-directories. This is how debootstrap --merged-usr works, and also how a system with usrmerge installed continues to work afterwards. It has the advantage that it works for all files, even those that get their paths hard-coded in various places: after undergoing this transition, /PATH and /usr/PATH can be used interchangeably (for any PATH in one of the directories that was historically on the rootfs). This is the result that I think most people mean when they say "the /usr merge" or "merged /usr". The other mechanism is migrating things from the rootfs into /usr individually, on a per-package basis. GLib's move from /lib/MULTIARCH to /usr/lib/MULTIARCH is a typical example. I think it's misleading to refer to this as "merged /usr" or "/usr merge" - although it can be *a step towards* that - because in most cases, after this transition, the two paths are *not* equivalent (one exists, the other doesn't), unless the first mechanism has *also* been used. > Libraries are easy to move since the linker will find them no matter > where they are installed, but moving the binaries too will require > merging older systems. Yes. I think some people (perhaps including Guillem?) might be advocating including executables in the second mechanism described above by moving them, on a per-package basis, to the root filesystem, and creating compatibility symlinks on the root filesystem if it has not undergone the /usr merge, like /bin/plymouth -> /usr/bin/plymouth and /sbin/iptables -> /usr/sbin/iptables. However, so far, this is rare (plymouth and iptables are among only a few examples on my laptop) and if adopted, it seems likely to be a slow transition: most of the affected packages are exactly those that are critical for boot, so their maintainers tend to be quite conservative. One thing to watch out for with this approach is that the symlinks must be created from the maintainer scripts instead of being shipped in the data.tar.*, because otherwise they would break the usrmerge-style approach to achieving merged /usr. Another issue with this approach is that it has quite a lot of moving parts (see recent upgrade issues with libgcc1 and libgcc-s1 for an example of how even a very experienced maintainer can reach unexpected situations in a transition like this). smcv