Package: dpkg
Version: 1.19.7
Severity: normal
Tags: unreproducible
Maintainers have seen bugs in various packages where an old file (one
that was shipped in an old .deb, but not under the same name in a new
.deb) appears to have been retained on-disk rather than deleted. At some
later time, perhaps months or years later, that file causes an upgrade
failure triggered by the superseding file moving from one directory in
a search path to another.
I was involved in investigating an instance of this in GLib, but
I've recently been shown examples of similar things happening in other
packages, so I think this might be more common than we'd thought (although
still rare). Please see below for summaries and links.
Because some maintainers believe the best approach to the "/usr merge"
is for each package that has historically been on the root filesystem to
carry out its own migration from / to /usr, this seems likely to occur
increasingly often as more packages do that transition.
My questions about this:
- Is/was there a known dpkg bug that could cause this?
- Is there anything that individual packages should be doing when they
move files into different directories in a search path, to work around
this?
- Is there anything that dpkg could/should be doing to help?
When I say /lib/MA or /usr/lib/MA below, I mean the multiarch library
directory.
GLib (#896019 and friends)
--------------------------
In GLib, we've had several reports of an obsolete file like
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.0 somehow being kept when
it should have been superseded by a newer version like
/lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.0. Much later, when the
intended path for this library changed from /lib/MA/libglib-2.0.so.0.* to
/usr/lib/MA/libglib-2.0.so.0.*, ldconfig(8) would create symlinks like:
/lib/MA/libglib-2.0.so.0 -> libglib-2.0.so.0.4200.0
/usr/lib/MA/libglib-2.0.so.0 -> libglib-2.0.so.0.5600.0
and because /lib/MA has higher precedence in the search path than
/usr/lib/MA, the older version in /lib/MA was preferred, and packages
with a versioned dependency on newer GLib releases started failing.
- Report: <https://bugs.debian.org/896019>
- Report: <https://bugs.debian.org/894763>
- Technical committee discussion: <https://bugs.debian.org/911225>
(I haven't yet implemented the suggested workaround in GLib)
libcrypt (#948318)
------------------
Similar to the GLib bugs above, /lib/x86_64-linux-gnu/libcrypt-2.25.so
somehow wasn't deleted on upgrade from glibc 2.25 to 2.26+. Years later,
the canonical path of libcrypt.so.1 changed from /lib/MA to /usr/lib/MA
during the transition to libxcrypt. Similar to the GLib bugs, ldconfig(8)
created a symlink /lib/x86_64-linux-gnu/libcrypt.so.1 -> libcrypt-2.25.so
which was higher-precedence than the one in /usr/lib/MA, causing programs
that reference newer libcrypt symbols to fail.
- Report: <https://bugs.debian.org/948318>
systemd (#945582)
-----------------
This one is a bit different: an old copy of systemd-machine-id-setup in
/usr/bin takes precedence over a new copy in /bin, and has a lockstep
dependency on an equally old libsystemd-shared-241.so, but dpkg correctly
*did* remove that library.
I don't think this is necessarily the same thing, because the systemd
maintainers say systemd never installed systemd-machine-id-setup into
/usr/bin and has always put it in /bin. Nobody involved in that bug
knows how it got into /usr/bin.
However, if an executable legitimately migrated from /usr/bin to /bin,
a similar failure mode could happen if the old executable somehow isn't
deleted during the dpkg transaction.
- Report: <https://bugs.debian.org/945582>
--------
Any ideas?
smcv
