1. Forum
  2. Usenet
  3. LINUX.DEBIAN.MAINT.GTK.GN

  • Review/testing requested for gnome-team/glib!9: cleaning up old GLib fr

    From Simon McVittie@21:1/5 to All on Mon Oct 5 16:10:02 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)