On Fri, 20 Nov 2020 at 11:12:20 +0100, Ansgar wrote: > On Fri, 2020-11-20 at 10:19 +0100, Adam Borowski wrote: > > On Fri, Nov 20, 2020 at 09:35:42AM +0100, Ansgar wrote: > > > As far as I know nothing broke catastrophically over the last releases > > > with merged-/usr. > > > > Unless you look at dpkg or attempts at speeding up bootstrap. > > > > See > > https://salsa.debian.org/glibc-team/glibc/-/commit/49d137c4392cb1144f2313f78f31466aaa169b75 > > for an example.
Trying to transition from /lib to /usr/lib in the way that is advocated by some people who don't like usrmerge (one package at a time, without using usrmerge or something equivalent) can unfortunately *also* cause transitional brokenness: see <https://salsa.debian.org/gnome-team/glib/-/commit/1f9c505abe2639296615d13c048227a3df378576>. (I would appreciate wider testing of the glib2.0 versions in experimental that attempt to resolve this, particularly by people whose systems are *not* merged-/usr. Merge requests against the debian/experimental branch are also welcome.) > The good news here is that shipping bash as /usr/bin/bash (instead of > /bin/bash) solves that problems as dpkg will just install it under > /usr/bin/bash. No aliasing over symlinks involved. I do agree with Ansgar that it seems good to have a timeline for making merged /usr the only supported layout. I don't agree with the implication that it's trivial to get there. There will probably be regressions - but we have a lot of clever people in this project, and if we pull the lever soon after bullseye is released, we have an entire release cycle to sort out regressions and still be on time for Ansgar's proposed timeline. (In an attempt to forestall people disputing that merged /usr has benefits: please see my responses to previous threads on this topic, in particular <https://lwn.net/ml/debian-devel/20181121140542.ga31...@espresso.pseudorandom.co.uk/> almost exactly 2 years ago, for quite a lot of words about that which I will not repeat here.) I agree that if we were designing a new dpkg-based OS that did not have legacy/upgrade-path constraints, we should put all the OS files in /usr in the .deb, and do something centralized to provide symlinks bin -> usr/bin and so on (either ship them in base-files, or use something resembling systemd-tmpfiles to make them exist declaratively, or just create them once during installation). However, we *do* have legacy/upgrade-path constraints: * Existing packages have paths like bin/bash in the .deb. * Existing installed systems have files on disk at paths like /bin/bash. * We cannot avoid the need for the path /bin/bash to exist (whether it's a regular file or involves a symlink /bin -> usr/bin or /bin/bash -> /usr/bin/bash), because existing scripts start with #!/bin/bash (and similarly /lib/ld-linux.so.2, /lib64/ld-linux-x86-64.so.2 etc. must continue to exist at those paths, with or without the help of symlinks, otherwise no binaries will run). So we need a way to get there from here. The only possibilities I can see for that within the framework of a dpkg-based OS are: * Aliasing via symlinks: Something magics /bin -> usr/bin, etc., symlinks into existence, and dpkg continues to tolerate unpacking over them, providing a per-installation flag day to move to merged /usr. usrmerge is an implementation of this approach, debootstrap --merged-usr is another. Individual systems can do this transition at any time (many have already done so), and they will get the benefit of merged /usr (in particular, a class of avoidable bugs can no longer affect them) after they have passed the flag day. * Package-by-package migration: For every package that ships a file in /bin, /sbin, /lib* whose path might have been hard-coded elsewhere, the maintainer of that package takes action to move the file into /usr. If the file's full path might have been hard-coded elsewhere (/bin/bash, etc.), the maintainer scripts must additionally create an unmanaged symlink /bin/bash -> /usr/bin/bash, etc. - similar to what was done to move /usr/bin/chacl in src:acl to /bin, but in reverse. And then, to get the benefits of merged /usr, we have to wait for *every* package to stop shipping anything in /bin, /sbin, /lib*, and *then* have a usrmerge-like per-installation flag day at which the collection of symlinks /bin/bash -> /usr/bin/bash, etc. are replaced by a single symlink /bin -> usr/bin. * Combine those two strategies, while arguing about which one is better, and hopefully minimizing the extent to which proponents of one approach prevent the other approach from proceeding. (In the absence of consensus, this is what is happening in practice.) Packages like bash that install files whose traditional paths are on the root filesystem and are hard-coded into other packages cannot safely move their files into /usr, without having to take other action to ensure compatibility, until one of those strategies has already happened. In all three cases, Debian-as-a-project does not get the full benefit of merged /usr until all installations that remain supported have had their per-installation transition; and in all three cases, we cannot ship /bin -> usr/bin, etc. in base-files until after every supported system has undergone that transition. So if Debian 12 is the first to make merged /usr mandatory during upgrade, as Ansgar proposes, then Debian 13 would be the first release where base-files could safely ship those symlinks. I agree that aliasing via symlinks has a complexity cost for low-level packages like dpkg and debootstrap clones. One way to mitigate this would be to make the transitional period as short as we can (which is essentially what Ansgar is proposing, I think), so that some release of Debian (12 in Ansgar's proposal) can guarantee to be merged-/usr, after which we have the option to take away the scaffolding that we used to get there (Ansgar proposes that this should happen between Debian 12 and 13). There's certainly an argument to be made that since we are *already* paying this complexity cost, we might as well get the benefit from it as soon as we can. Package-by-package migration touches a large number of packages, and we don't get any benefit from merged /usr until it has *finished*. Previous experience in Debian from migration to multiarch library directories (started in around 2012, highly unlikely to finish in 2020) and migration to /usr/share/doc (started in 1999, finished in 2008) suggests that this is not going to be fast - to speed this up, I think we would have to be a lot more willing to accept NMUs of core packages. However, the longer we take, the longer the period will be in which we are encountering transitional bugs. It is not obvious to me that this is desirable, and in particular the need to set up per-executable compat symlinks actively works against the ongoing goal of reducing the amount of imperative code in maintainer scripts. The third option combines the weird transitional states affecting low-level packages from the first option with the unbounded duration of the second option, while letting individual maintainers delay the first option happening by asserting that it's wrong and we should be following the second. Looking at our friends in other distros, it's perhaps instructive to compare Fedora with openSUSE (note that both use the same package manager). Fedora took the aliasing-via-symlinks approach, and as I understand it, was able to go from the traditional layout to merged /usr everywhere in a single 6-month release cycle. openSUSE took a package-by-package approach, and as far as I'm aware, is still working on it. smcv