On Thu 02 Jan 2020 at 19:49:45 (+0100), Sven Hartge wrote:
> 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.
Not ideal, but really not much more than
if /bin is link to usr/bin:
prefix /bin/foo with /usr
at appropriate points in scripts, no?
> >> 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.
It's a simlar problem, isn't it? If the chroot uses a split
configuration, most of the problems go away on account of the
symlinks. It's just the paths that get realname-d which need
fixing up as above.
> >> 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.)
That would seem easy for them to fix with a simple rename of their
custom versions of the libraries.
> But, to summarize: I'd have liked for this change to be done in a
> different way with *all* systems-maintainers in board.
Reading #914897, that didn't seem likely as views were somewhat entrenched.
Cheers,
David.
