[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#911225: marked as done (tech-ctte: Advice on stale libraries in a higher-precedence path entry)

Your message dated Wed, 20 Mar 2019 09:34:35 +0100
with message-id <1cc9400c0f4f4a8feb29bcd41dc0f832@debian.org>
and subject line Re: Bug#911225: tech-ctte: Advice on stale libraries in a  higher-precedence path entry
has caused the Debian Bug report #911225,
regarding tech-ctte: Advice on stale libraries in a higher-precedence path entry
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org

911225: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911225
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
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

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

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

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?


--- End Message ---
--- Begin Message ---
The last time this was discussed was in our IRC meeting in November:

The advice provided by Didier was found sensible by several members of the Technical Committee. Simon said that while he agreed it was sensible, it was more complex than expected. Simon is free to implement whichever solution he finds both sensible and technically sound, but the committee has provided the advice requested.

Therefore, I'm here closing this bug as resolved.


--- End Message ---

Reply to: