Re: merged /usr vs. symlink farms
On Thu, Aug 19, 2021 at 11:17:17AM +0100, Simon McVittie wrote:
> In this specific case, I think the thing you're having a problem with is
> the gradual, file-by-file migration of executables into /usr by individual
> packages and individual packages' maintainers. That's not merged-/usr:
> merged-/usr does the migration all at once, by creating the aliasing
> symlinks (and then we can clean up the contents of data.tar.* to put all
> /usr-like files below /usr at our leisure, during the next release cycle,
> without needing maintainer script glue).
FWIW, from following the discussion, I've become more and more
convinced that a symlink farm is *not* the right answer, regardless of
whether it is done centrally or via individual packages moving files
and created symlinks if necessary in individual maintainer scripts.
The symlink farm idea seems to be pushed by the dpkg team, because
it's clear that supprorting directory aliasing by having /bin ->
usr/bin, /lib -> /usr/lib, etc., top-level symlinks does create more
work for the dpkg team, and they seem to be put off by the fact that
they hadn't agreed to do that work, and they appear to claim that they
weren't consulted in advance.
But if we are going to follow how Fedora, Solaris, etc, have been
moving elimitating the traditional /{bin,sbin,lib} and
/usr/{bin,sbin,lib} split, directory aliasing the way Fedora, Solaris,
etc. have done things is the only way to go.
Perhaps the dpkg team should have been consulted earlier, and if they
could have convincingly argued that this was a show stopper, or they
had demanded that someone else should have provided the engineering
effort to make dpkg handle the directory aliasing *first*, perhaps we
shouldn't have even stated in the /{bin,sbin,lib} ->
/usr/{bin,sbin,lib} unification journey, despite the fact that all of
the other distributions have gone down that path.
Speaking personally, I'm not super excited about /usr unification.
But then again, I don't work on projects such as embedded systems,
containerized systems, etc., which seem to benefit from /usr
unification, and there *is* value in being similar to other Linux
distributions.
In any case, that's water on the bridge. We are where we are, and
stopping midway through the /usr unification journey would be a far
worse outcome. And given that we've already lost the benefits of the
split /usr architecture (specifically, the ability to boot without
/usr being mounted, which I recognize is not as useful in the 21st
century) --- we should push on and finish the job.
Given that symlink farms have all sorts of downsides, the best path
foward seems to be to teach dpkg about the top-level directory
aliasing, and simply handling this appropriately. Issues such as the
/bin/sh vs. /usr/bin/sh unification causing problems with /etc/shells
is an issue all distributions have to deal with anyway, and we can
look to see how they have handled it.
Cheers,
- Ted
Reply to: