David Wright <deb...@lionunicorn.co.uk> wrote: > On Wed 01 Jan 2020 at 18:48:00 (+0100), Sven Hartge wrote: >> David Wright <deb...@lionunicorn.co.uk> wrote: >>> But this does follow the (snipped) comment 'the "/usr Merge" that >>> might hit a fan someday'. For those *not* preparing packages for >>> Debian and/or other distributions, can anyone express a downside to >>> usr-merge, ie for typical "user/consumers".
>> For me the biggest downside was that "dpkg -S", "dlocate" and >> "apt-file search" and the web-equivalent stopped working reliably, >> because the final path in the filesystem is no longer the same as it >> is in the package. > Yes, I notice that the bug (134758) dates back 18 years and originally > involved the old /usr/X11R6/bin /usr/bin/X11 symlink. It complicates > using dpkg -S to search for one specific path (in a script, say), but > for interactive use it's enough to remove the leading / to avoid > misses caused by usr-merge. (There are already misses caused by > alternatives, and files created at installation time.) Not everything is interactive use and having to special-case newly installed versus upgraded systems to have the correct matching type is really not ideal. >> It also broke some internal CI/CD where the wrong paths were used when >> the CD chroot was built with usr-merge active but the deployment target >> was not usr-merged. The same has happened for the Debian buildds. > I thought I was avoiding that by excluding package-builders. Or is > this something else entirely? Those are not packages that are built but software/configuration/file distribution via different ways. >> And it also broke some 3rd party vendor packages which had the same >> directory in /lib and /usr/lib, but with different contents. > What do these vendors do on conventional (non-Debian/non-linux) > systems that have ceased to have any /lib long ago? In this case the vendor only ever supported Debian and Ubuntu. (This is a very edge-case specialty-use software.) But, to summarize: I'd have liked for this change to be done in a different way with *all* systems-maintainers in board. S! -- Sigmentation fault. Core dumped.
