Re: merged /usr vs. symlink farms
On Thu, 19 Aug 2021 at 10:06:27 +0200, Helmut Grohne wrote:
> You keep proposing adding /bin/foo -> /usr/bin/foo symbolic links via
> maintainer scripts.
I'm not proposing this! I'm trying to *not* need to do that in any more
packages, and instead do usrmerge or equivalent, so that individual
packages' maintainers don't have to take per-package action to move
their files from /bin,/sbin,/lib* into /usr while creating compatibility
symlinks for non-merged-/usr systems.
However, I know Guillem and some others object to that strategy, so I'm
trying to also be clear about which of the fixes that are necessary with
usrmerge would be equally necessary for a symlink-farm-based strategy,
if people who prefer a symlink-farm-based strategy gain consensus for
that strategy.
Exactly how the symlinks in a symlink-farm-based strategy are created
is orthogonal to whether packages need to avoid hard-coding (e.g.) /bin/env
or /usr/bin/sh, in filesystem layouts where both paths with and without /usr
exist, which would break the installation of that package onto the traditional
filesystem layout where only /usr/bin/env and /bin/sh exist.
I agree that if a symlink-farm-based strategy is used, then delegating the
creation of the individual symlinks to individual packages' maintainer
scripts has practical problems, and it would be better to centralize the
creation of those symlinks (somehow). I think it's up to the people who
want to generate symlink farms to solve that problem.
Note that what the Technical Committee resolved as the desired state
is merged /usr with aliasing symlinks such as /bin -> usr/bin, not a
symlink farm with individual symlinks such as /bin/sh -> /usr/bin/sh,
precisely because we are concerned about the number of "moving parts"
involved in setting up a symlink farm. (Speaking for myself here, not
for the TC, but I don't think I'm misrepresenting anyone's position on
the symlink farm approach by saying this.)
> The collateral damage of the merged-/usr
> work to the work I'm interested in is huge.
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).
The aliasing symlinks create problems for dpkg, as Guillem has documented
elsewhere, and as a result some people are pursuing a symlink-farm-based
alternative to the aliasing symlinks. If that symlink-farm-based approach
is taken, then yes, we will need either a centralized mechanism to
construct those symlink farms, or a lot of maintainer script glue
(and, again, the Technical Committee's recommendation was to not do that).
The packages that needed maintainer-script changes *before* merged-/usr,
in order to enable merged-/usr, are those that previously shipped files
at both /foo and /usr/foo in their data.tar.*, such as
coreutils (<< 8.24-1) for /{usr/,}bin/touch. The reason they need
maintainer script code is that we still support non-merged-/usr systems;
their maintainer scripts are a no-op on merged-/usr systems, so if the
bookworm release only supported merged-/usr, then their maintainer
script code could disappear during the bookworm+1 cycle.
I agree that *those* maintainer scripts are creating extra work for
people working on DPKG_ROOT and similar things, and would not have been
necessary if we had not gone in the direction of merged-/usr in around
2016. If we can make those unnecessary, or more declarative, then that
would be a good direction.
smcv
Reply to: