On Thu, 29 Nov 2018 13:34:24 +0100, KatolaZ wrote in message
<20181129123424.ojmbaljuam77mz5m@???>:

> On Thu, Nov 29, 2018 at 09:18:38PM +0900, Olaf Meeuwissen wrote:
> > Hi Karl,
> >
> > karl@??? writes:
> >

> > > Rich Moen:  
> > >> Quoting KatolaZ (katolaz@???):  
> > > ...  
> > >> > # ldd /bin/ps | grep "/usr"
> > >> >         liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1
> > >> > (0x00007fd7f6ebc000)  

> > >>
> > >> Yeah, those two are really annoying. FWIW, my server system has
> > >> older versions of those two utilities that do _not_ have that
> > >> (IMO) build error. Local packages will be an immediate resort,
> > >> when/if I hit that.
> > > ...
> > >
> > > Attached is a program to find possible /-/usr link breakage.
> > > It could possible be changed into an un-usrmerge-program if we
> > > want.
> >
> > Looks like your script is ignoring any symlinks in /bin and /sbin
> > that point to stuff in /usr ...
> > Or elsewhere not on the partition that holds / ...
> > :-/
> >
>
> Actually, that would amount to getting down a quite deep rabbit
> hole. Those links, even if they exist, might have been created by the
> postinst script of some package, or by the local sysadmin. In the
> former case, removing them blindly will probably cause at least a dpkg
> error at the next upgrade of the corresponding package.

..we can use those dpkg errors to help automate bug reports.

..and wherever we disagree with Debian's merge etc policy,
a Devuan fork .deb can be as simple as having our postinst
script flip a symlink around, or copying files into /sbin
or /bin, rather than symlinking them there.

> In the latter
> case, removing them blindly might possibly cause breakage to some
> functionality put in place by the sysadmin and/or undesired
> side-effects.

..dpkg-divert is handy in such cases.

--
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.