Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib
On Sat, 15 Feb 2020 at 21:24:38 +0100, Michael Biebl wrote:
> While I think the underlying issue should be investigated (tbh the
> thought that dpkg get's confused / its db corrupted so does not properly
> clean up those old files is quite disconcerting), couldn't we just
> switch the order of /lib and /usr/lib and make /usr/lib the preferred path?
Maybe, but it could result in the opposite bug in some cases. Consider
the SONAME libfoo.so.0, and assume the multiarch tuple is MA.
1. libfoo.so.0.1.2 is in /lib/MA
2. maintainer moves libfoo.so.0.2.3 from /usr/lib/MA to /lib/MA because
some early-boot service needs libfoo.so.0
3. somehow libfoo.so.0.1.2 is not deleted during the upgrade
4. ldconfig creates libfoo.so.0 -> libfoo.so.0.1.2 in /lib/MA
and libfoo.so.0 -> libfoo.so.0.2.3 in /usr/lib/MA
(several years later)
5. now we have libfoo.so.0 -> libfoo.so.0.1.2 in /lib/MA and
libfoo.so.0 -> libfoo.so.0.4.2 in /usr/lib/MA
6. we change ld.so.conf.d so that /usr/lib/MA is preferred over /lib/MA
7. programs that depend on libfoo0 (>= 0.4.2) get libfoo.so.0.1.2, and
are broken, because symbols introduced since 0.1.2 are missing
However, in many cases we might dodge that bullet in practice because the
transition to multiarch happened between steps 4 and 5, and /usr/lib/MA
and /lib/MA are both preferred over /usr/lib and /lib. For example,
libdbus-1-3 transitioned from /usr/lib to /lib in 1.2.16-1, from /lib
to /lib/MA in 1.4.12-3, and from /lib/MA to /usr/lib/MA in 1.13.10-1;
so it might get a bug equivalent to #896019 if we don't reverse the
priorities of /lib/MA and /usr/lib/MA, but it can't have the bug I
describe above if we do reverse their priorities.
smcv
Reply to: