Re: usr-merge, was Re: Back to systemd [was: Re: New list for Raspbian? (was: Re: systemdq)]
David Wright <deblis@lionunicorn.co.uk> wrote:
> On Wed 01 Jan 2020 at 18:48:00 (+0100), Sven Hartge wrote:
>> David Wright <deblis@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.
Reply to: