Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib
Hello,
On Tue, Feb 18, 2020 at 10:10:05PM +0100, Marco d'Itri wrote:
> On Feb 18, Simon McVittie <smcv@debian.org> wrote:
>
> > 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.)
> We do not just have a consensus, this has also been a fact for a long
> time now:
.. and is completely unrelated to merged-usr (?!).
>
> kmod (25-2) unstable; urgency=medium
>
> * Moved the libraries to /usr/lib/. (Closes: #894566)
>
> -- Marco d'Itri <md@linux.it> Sat, 17 Nov 2018 01:56:00 +0100
>
> > 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.
> This does not matter as long as we have to support un-merged-/usr
> systems.
>
> > 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
> Slow, and also a lot of work for no significant benefits.
As I see it there are two possible ways forward:
a/ make merged-usr mandatory in one stable release and in the next
we can just install the files under /usr. No per-package symlinks
needed.
b/ someone volunteers to write a debhelper addon which runs after
dh_install, detects files in /lib, /bin and /sbin, moves them
into /usr and generates the needed postinst code doing the compat
symlinks for non-merged systems.
The third option that I see as a no-go is that each package maintainer
implements this on their own because:
1. Getting this finished will take way too long.
2. Manually written maintainer scripts is well known source of bugs.
3. Broken maintainer scripts are a horrible user experience.
4. People will keep repeating the mistake of shipping the symlinks
in the package (once they realize manually written maintainer scripts
are horrible?!) and thus break their package on merged-usr systems.
5. Doing the work this way will consume too much resources for no gain.
6. People being fine with the current status quo will not like 5/
further contributing to 1/.
I think it's time we either try to figure out if/how we can actually
get a decision on doing a/ soon, or for those who can't live with
one release making merged-usr mandatory then start working on
that debhelper needed to do b/ now!
(Also when/if doing b/ or the 'no-go' option someone might want to think
about how per-package symlinks generated in postinst is going to play
nice with Essential: yes packages which are supposed to work
unconfigured.)
Regards,
Andreas Henriksson
Reply to: