On Mon, 19 Jul 2021 at 11:33:49 +0200, Stephan Lachnit wrote:
> We could start with collecting the packages that install to /bin*
> instead of /usr/bin, and adjust the packaging so that they don't do
> that. [...] At this point, it shouldn't
> matter if you run a merged usr system or not, or am I forgetting
> something?
This would have part of the practical effect of merged-/usr, but not all
of it. It could still be a useful step forwards, but we should not view
it as being entirely equivalent to merged-/usr.
What we have now on unmerged-/usr systems, using /bin/bash and
/usr/bin/perl as examples of Essential programs that use the two paths:
bash perl
/bin/foo physical location (does not exist)
/usr/bin/foo (does not exist) physical location
What we would have on unmerged-/usr systems if we do as you suggest:
bash perl
/bin/foo exists via symlinks (does not exist)
/usr/bin/foo physical location physical location
Merged-/usr for comparison:
bash perl
/bin/foo exists via symlinks exists via symlinks
/usr/bin/foo physical location physical location
As you can see from those tables, a package that hard-codes /usr/bin/bash
is currently considered broken, but would work with either your proposal
or merged-/usr. Conversely, a package that hard-codes /bin/perl would
still be considered broken, would *not* work with your proposal, but
would work on merged-/usr systems.
(Obviously the same applies when considering hard-coded paths in /sbin,
/lib, etc. instead of /bin, in particular the ELF interpreters like
/lib64/ld-linux-x86-64.so.2 that are hard-coded into every
dynamically-linked executable)
Meanwhile, various shared libraries are also moving from /lib to
/usr/lib. One potentially serious problem with that on non-merged-/usr
systems is that we still don't understand why the bugs discussed
in https://bugs.debian.org/911225 and https://bugs.debian.org/949395
happened, and a similar thing could potentially happen to /lib libraries
other than GLib. The script that GLib uses to work around this is generic,
and could be used in other affected packages if required, but it's larger
and more fragile than I'm really comfortable with.
(Merged-/usr systems cannot suffer from bugs like the ones discussed in
#911225, because the paths involved are the same directory.)
smcv
