On Wed, 04 Apr 2018 at 10:41:01 +0300, Adrian Bunk wrote: > On Wed, Apr 04, 2018 at 09:10:31AM +0200, Axel Beckert wrote: > >... > > ~ → ldd /usr/lib/arm-linux-gnueabihf/glib-2.0/gio-querymodules > > libgio-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgio-2.0.so.0 > > (0x76e3f000) > > libgobject-2.0.so.0 => > > /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0 (0x76df7000) > > libgmodule-2.0.so.0 => > > /usr/lib/arm-linux-gnueabihf/libgmodule-2.0.so.0 (0x76de4000) > > libglib-2.0.so.0 => /lib/arm-linux-gnueabihf/libglib-2.0.so.0 > > (0x76d0d000) > >... > > This looks like there is a libglib-2.0.so.0 in /lib/arm-linux-gnueabihf/ > that shouldn't be there, and this takes precedence over the more recent > one from the Debian package that gets installed to /usr/lib.
My thoughts exactly. What's that doing there? I would have expected that removing the old libglib2.0-0 package would delete that. Please try: ls -il /lib/arm-linux-gnueabihf/libglib-2.0.so* ls -il /usr/lib/arm-linux-gnueabihf/libglib-2.0.so* Since you were seeing these symbol lookup errors while packages are being configured, I wonder whether we're seeing something like this: * new libglib2.0-0 is unpacked - /usr/lib/arm-linux-gnueabihf/libglib-2.0.so.0 has been created (it is hard-linked to /usr/lib/arm-linux-gnueabihf/libglib-2.0.so.0.dpkg-new or something) - /lib/arm-linux-gnueabihf/libglib-2.0.so.0 has not yet been deleted (it is hard-linked to /lib/arm-linux-gnueabihf/libglib-2.0.so.0.dpkg-old or something) * assorted other packages are unpacked * assorted other packages are configured - in your situation, we fail here and never get further * new libglib2.0-0 is configured - /lib/arm-linux-gnueabihf/libglib-2.0.so.0 should be deleted here If that guess is correct, then we're going to have difficulty whenever we migrate a library from a higher-precedence directory (/lib/MULTIARCH) to a lower-precedence directory (/usr/lib/MULTIARCH), and we'd have the same issue moving a non-multiarch library from /lib to /usr/lib. The multiarch directories (from ld.so.conf.d) are higher-precedence than the non-multiarch directories (hard-coded), so we only coincidentally avoided this for the migration from non-multiarch to multiarch. GLib maintainers following testing/unstable wouldn't have seen this failure mode, because we would be very likely to be upgrading from a version that is recent enough that it already has all the same symbols as the one in /lib; but it would be a problem for stretch -> buster upgrades. smcv