Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib
On Tue, 18 Feb 2020 at 12:44:18 +0100, Marco d'Itri wrote:
> On Feb 16, Simon McVittie <smcv@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
Reply to: