Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib
On Sat, 2020-02-15 at 20:35:58 +0100, Marco d'Itri wrote:
> On Feb 15, Sven Joachim <svenjoac@gmx.de> wrote:
> > True, but there seem to be a relatively high number of systems where an
> > old unowned version of some library is lying around under /lib (possibly
> > because the dpkg database became corrupted at some point and so dpkg
> > forgot about the file; see the dpkg bug #949395), and when that library
> > starts be installed under /usr/lib, this will trigger symbol lookup
> > errors and the like. See #896019 and #948318 for examples.
> Somebody reported a similar problem about libcrypt.so.1, which moved
> from /lib/ (provided by libc) to /usr/lib/ (provided by libxcrypt).
If the problem was with the new pathname disappearing, then that's just
yet another instance of the usrmerge-via-symlinks collateral damage.
Moving a pathname to an aliased directory across different binary
packages can make the new pathname disappear depending on the unpack
order. Because, if dpkg unpacks the package now owning the new pathname,
and then unpacks the package that has stopped owning the old pathname,
when it removes that, it will end up removing the aliased pathname and
will not notice any Replaces takeover due to the directory aliasing.
> Since libcrypt.so.1 has been in /usr/lib/ for three months now without
> any other unexpected issues then I think that we can be very confident
> that there is no reason whatsoever to install anything outside of /usr
> anymore.
Then the libcrypt package is broken on dist upgrade and can render
usrmerge-via-symlinks systems unusable. Package doing a proper /usr-merge
migration within the same binary package are of course perfectly fine
everywhere, and also of course non-usrmerged systems are always fine.
The irony in all this is that the usrmerge hack that got introduced to
make the switch faster and easier, has been consistently making a
proper /usr-merged switch more fragile and difficult… I need to create
a wiki with the increasing list of issues and a big fat note stating
that these broken deployments are unsupported by dpkg.
Regards,
Guillem
Reply to: