Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib
On Wed, Feb 19, 2020 at 10:19:35AM +0000, Simon McVittie wrote:
> On Tue, 18 Feb 2020 at 23:20:11 +0100, Andreas Henriksson wrote:
> > 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.
>
> This could work for non-Essential packages, or for Essential packages
> whose paths are not, in practice, hard-coded.
>
> However, for Essential packages, I don't think this would be implementable
> in postinst, except by having the postinst be a statically-linked binary
> with no dependencies, or a busybox-static sh script. Otherwise we get
> this situation:
>
> - starting point: /lib64/ld-linux-x86-64.so.2 exists,
> /usr/lib64/ld-linux-x86-64.so.2 does not
> - (preinst runs, if any)
> - new libc6 is unpacked: now /usr/lib64/ld-linux-x86-64.so.2 exists,
> and /lib64/ld-linux-x86-64.so.2 does not
> - postinst runs
> - if it's dynamically linked: /lib64/ld-linux-x86-64.so.2
> doesn't exist so it fails to start
> - if it's a script with a dynamically-linked interpreter: ditto
> - if it runs dynamically-linked executables: ditto
It's insane to suggest that "merged /usr" *needs* to include the dynamic
linker. It's part of the ABI, so we can be perfectly fine by not moving
it around at all.
Even so, if we want to do so, this can be done correctly by a preinst
script in new libc, by way of a script that does the following:
cp -a /lib/<dynamic linker name> /usr/lib/<dynamic linker name>
ln -sf /lib/<dynamic linker name> /usr/lib/<dynamic linker name>
The first of the above two creates the new file; the second replaces the
old file, atomically, by a symlink.
The unpacking of new libc will then overwrite /usr/lib/<dynamic linker name>,
and all is well.
--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
Reply to: