Bug#911225: tech-ctte: Advice on stale libraries in a higher-precedence path entry

[Simon McVittie]

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