Hi. On Wed, May 19, 2021 at 02:23:40PM -0400, Greg Wooledge wrote: > On Wed, May 19, 2021 at 02:15:29PM -0400, Polyna-Maude Racicot-Summerside > wrote: > > Why would a package I get from a git repository be supportable but a > > package I save some packaging time and get from another source (Kali, > > Ubuntu for example) would become unsupportable ? > > Because things you pull from git and install in /opt or /usr/local or > even $HOME do not interfere with the Debian system.
It's not true in the case of /usr/local. Any library that's installed in /usr/local/lib will be processed by ldconfig (see /etc/ld.so.conf.d/*.conf), possibly leading to all kinds of mess. > They don't create dependency issues within the dpkg database, nor do > they overwrite essential system libraries or files, But to ld.so any library in /usr/local takes priority over /usr, i.e. you don't need to overwrite the library to break the binary, providing ABI-incompatible library at /usr/local (and running ldconfig) is sufficient. And, last time I've looked at $PATH, /usr/local/bin is listed before /usr/bin, which can be the source of funny things too. > An Ubuntu or Kali package, especially a badly built one, can cause *all* > kinds of havoc. Even some third-party repositories set up by Debian > developers have been notorious for causing these kinds of problems in > the past -- take a look at the history of the "debian multimedia" package > repositories, in particular. And this very list contains numerous examples of "I forgot about that library that I've installed at /usr/local, but it broke X and Y years after". Package breakages are bad, there's nothing to argue here. But breaking ld.so is equally bad. Reco
