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