--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: tech-ctte: Advice on stale libraries in a higher-precedence path entry
- From: Simon McVittie <smcv@debian.org>
- Date: Wed, 17 Oct 2018 10:59:09 +0100
- Message-id: <20181017095909.GC19253@espresso.pseudorandom.co.uk>
Package: tech-ctte
Severity: normal
I would like advice from the technical committee on
<https://bugs.debian.org/896019>. I am not asking for anyone to be
overruled.
GLib (src:glib2.0) consists of multiple libraries. The ones that are
relevant for this bug are libglib-2.0.so.0, which is low-level, and
libgobject-2.0.so.0, which is higher-level. They come from the same source
package (indeed, in Debian they are even in the same binary package)
and are expected/required/assumed to be upgraded in lockstep:
higher-level libraries from src:glib2.0 are allowed to assume that
the lower-level libraries are at exactly the same version.
In stretch and previous releases, libglib-2.0.so.0 was installed in
/lib/MULTIARCH, ostensibly for the benefit of early-boot services. It
isn't clear to me whether any early-boot services actually ever took
advantage of this.
In buster, libglib-2.0.so.0 was moved to /usr/lib/MULTIARCH, because
versions >= stretch only support a separate /usr if there is an initramfs
that mounts it before running the main system's init, and in particular
/usr/lib/MULTIARCH will be available by the time init starts. This removed
some apparently unnecessary complexity from the packaging, which had to
move the libraries around (we couldn't just set ${libdir} to
/lib/MULTIARCH, because higher-level parts of GLib needed to be in
/usr/lib/MULTIARCH anyway).
/lib/MULTIARCH appears in /etc/ld.so.conf.d with higher precedence than
/usr/lib/MULTIARCH.
In #896019 and #894763, it appears that some upgraded systems somehow
still contain a copy of libglib-2.0.so.0.4200.0 (corresponding to
GLib from jessie) in /lib/MULTIARCH. We don't know how this can have
happened. There are suggestions that it might have been caused by
filesystem corruption or installed by third-party software.
When it does, ldconfig sees that the obsolete library
has SONAME libglib-2.0.so.0, and creates a symlink
/lib/MULTIARCH/libglib-2.0.so.0. This takes precedence over the
newer version of libglib-2.0.so.0 that is correctly installed in
/usr/lib/MULTIARCH, resulting in the new libgobject-2.0.so.0 failing
to load, because it uses symbols that are only present in the new
libglib-2.0.so.0.
Possible resolutions include:
* Do nothing; consider the systems with a leftover
/lib/MULTIARCH/libglib-2.0.so.0.4200.0 to be an unsupported local
misconfiguration (this is the status quo)
* Move libglib-2.0.so.0 back to /lib/MULTIARCH permanently, at a
long-term complexity cost
* Take steps to delete /lib/MULTIARCH/libglib-2.0.so.0.* during upgrade,
taking care to avoid deleting files that are really on
/usr/lib/MULTIARCH in merged-/usr systems, at a significant complexity
cost, with some risk of deleting necessary files if we get it wrong
* Advocate merged /usr where this class of problem cannot happen :-)
Do technical committee members (other than me) have any thoughts on this?
Thanks,
smcv
--- End Message ---