Am 15.02.20 um 23:11 schrieb Guillem Jover: > On Sat, 2020-02-15 at 20:35:58 +0100, Marco d'Itri wrote: >> On Feb 15, Sven Joachim <svenjoac@gmx.de> wrote: >>> True, but there seem to be a relatively high number of systems where an >>> old unowned version of some library is lying around under /lib (possibly >>> because the dpkg database became corrupted at some point and so dpkg >>> forgot about the file; see the dpkg bug #949395), and when that library >>> starts be installed under /usr/lib, this will trigger symbol lookup >>> errors and the like. See #896019 and #948318 for examples. > >> Somebody reported a similar problem about libcrypt.so.1, which moved >> from /lib/ (provided by libc) to /usr/lib/ (provided by libxcrypt). > > If the problem was with the new pathname disappearing, then that's just > yet another instance of the usrmerge-via-symlinks collateral damage. > > Moving a pathname to an aliased directory across different binary > packages can make the new pathname disappear depending on the unpack > order. Because, if dpkg unpacks the package now owning the new pathname, > and then unpacks the package that has stopped owning the old pathname, > when it removes that, it will end up removing the aliased pathname and > will not notice any Replaces takeover due to the directory aliasing. > >> Since libcrypt.so.1 has been in /usr/lib/ for three months now without >> any other unexpected issues then I think that we can be very confident >> that there is no reason whatsoever to install anything outside of /usr >> anymore. > > Then the libcrypt package is broken on dist upgrade and can render > usrmerge-via-symlinks systems unusable. Package doing a proper /usr-merge > migration within the same binary package are of course perfectly fine > everywhere, and also of course non-usrmerged systems are always fine. Those issues happen on non-usr-merged systems.
Attachment:
signature.asc
Description: OpenPGP digital signature