WIP: clean up unmanaged libraries
-
postinst: Clean up outdated copies of GLib to avoid upgrade issues
Old versions of the GLib libraries sometimes continue to exist after upgrade. It is not clear why, because dpkg is meant to clean up files that only existed in the old package during upgrade, and normally it does that successfully; but for some reason old files sometimes persist (see #949395, #911225). It is not clear whether this is a dpkg bug or some other root cause.
When the library is in the same directory as newer versions, this is harmless, because ldconfig(8) ensures that the libglib-2.0.so.0 symbolic link points to the newest version (using the version number from the suffix to disambiguate).
However, prior to version 2.56.0-5 we installed GLib into /lib/MULTIARCH, and since that version we install it into /usr/lib/MULTIARCH. ldconfig(8) maintains one libglib-2.0.so.0 symlink per library directory, and /lib/MULTIARCH is earlier in the search path than /usr/lib/MULTIARCH, so on non-merged-/usr systems we can find that an older version in /lib/MULTIARCH is chosen in preference to the newer version in /usr/lib/MULTIARCH, breaking versioned dependencies.
To resolve that, as discussed with the Technical Committee on #911225, we now attempt to detect the broken situation and solve it by moving the old version out of the way.
GLib seems to be particularly prone to this for whatever reason, but the same failure mode has been seen in other libraries that have moved from /lib to /usr/lib, such as libcrypt.so.1, and it could recur as other /lib libraries make the same transition in future. As a result, the clean-up-unmanaged-libraries script is designed to be usable for other libraries if that becomes necessary.