Review/testing requested for gnome-team/glib!9: cleaning up old GLib from /lib/<triplet>
Now that GNOME 3.38 is (mostly) in testing, I've finally implemented a
fix for the GLib upgrade issues referred to the technical committee in
#911225 "Advice on stale libraries in a higher-precedence path entry"
(see #896019, #955331, #954960). Sorry for the very long delay in
implementing this.
There's an autopkgtest, which passes on both unmerged-/usr and merged-/usr
systems, but because this is deleting important libraries at a system
level, I would very much appreciate review and testing from other
developers before I release this. See:
https://salsa.debian.org/gnome-team/glib/-/merge_requests/9
Briefly, GLib in stretch was installed in /lib/<triplet>, which is
higher-priority for the runtime dynamic linker than /usr/lib/<triplet>.
In buster, we moved it to /usr/lib/<triplet>. For reasons we still don't
understand, on a minority of systems a stale copy remains in /lib/<triplet>
and is not deleted, causing versioned dependencies to break.
I have now implemented approximately what Didier suggested in the technical
committee discussion: GLib's postinst looks for copies of GLib in
/lib/<triplet>. If they exist and are not managed by dpkg, and
/usr/lib/<triplet>/libglib-2.0.so.0 exists and *is* managed by dpkg, then
we move the stale copies into a new directory
/lib/<triplet>/removed-by-upgrade-bug896019 to stop them breaking
higher-level libraries.
One difference between Didier's recommendation and what I have actually
implemented is that I'm not checking the stale libraries against known
md5sums of the version of GLib in jessie. See the MR for rationale.
This bug does not affect merged-/usr systems, where the stale version can
still be present but is harmless. As a result, my workaround skips itself
on merged-/usr systems (unless run manually with --force).
This is mostly cleanup from stretch -> buster upgrades, since we don't
support skipping a version (although we could conceivably put it in a
buster point release after a *lot* of testing).
Please send any comments to the MR (preferred) or to debian-gtk-gnome. I'm
cross-posting to the technical committee to keep them in the loop, but not
opening a new tech-ctte bug for this.
Thanks,
smcv
Reply to: