On Sat, 11 Sep 2021 at 18:00:50 +0200, Andreas Metzler wrote: > On 2020-01-20 Simon McVittie <s...@debian.org> wrote: > > Maintainers have seen bugs in various packages where an old file (one > > that was shipped in an old .deb, but not under the same name in a new > > .deb) appears to have been retained on-disk rather than deleted. At some > > later time, perhaps months or years later, that file causes an upgrade > > failure triggered by the superseding file moving from one directory in > > a search path to another. > > I have got another instance in libgcrypt20 > <https://bugs.debian.org/984884> but the actual error (leaving files > behind) happened ages ago; the leftovers are from pre-stretch versions > of libgcrypt. > > These leftovers trigger an error now, because the library has moved from > /lib to /usr/lib in buster and ldconfig activates both the leftover and > the proper copy (by adding libgcrypt.so.20 symlinks). /lib has the > higher priority and wins.
This is the same failure mode as was seen in glib2.0, and we were never able to work out why. In the glib2.0 bugs, the leftover versions were older: from wheezy (we think) in #954960, and from half way through the wheezy -> jessie cycle in #894763, #896019 and #955331. I asked the Technical Committee for advice about how to deal with this in glib2.0, and we came to the conclusion that cleaning up the old library in the maintainer scripts was the least-bad option. There's a script in glib2.0 that can be called from a maintainer script to work around this. I've only used it for GLib, but it should work equally for any library that moved from /lib/MULTIARCH to /usr/lib/MULTIARCH, since it takes a bug number, a multiarch tuple and a SONAME as command-line options: https://salsa.debian.org/gnome-team/glib/-/blob/debian/bullseye/debian/clean-up-unmanaged-libraries Example use in a postinst (look for "cleanup"): https://salsa.debian.org/gnome-team/glib/-/blob/debian/bullseye/debian/libglib2.0-0.postinst.in GLib uses a generated postinst where #MULTIARCH# gets replaced by the multiarch tuple of the package. As far as I know, this is going to be necessary for any multiarch library that will use my clean-up-unmanaged-libraries script, because dpkg tells us the DPKG_MAINTSCRIPT_PACKAGE and DPKG_MAINTSCRIPT_ARCH, but there is no DPKG_MAINTSCRIPT_MULTIARCH. I'll open a separate wishlist bug for DPKG_MAINTSCRIPT_MULTIARCH, because that would be useful to have - GLib needed it anyway, even before the cleanup was implemented, to handle GIO plugins. smcv
