On Fri, Jul 28, 2017 at 12:04:54PM -0400, Greg Wooledge wrote: > > The concern is that you may have used some shared library to compile a > third-party program which is installed in /usr/local or /opt, or anywhere > else that's outside of Debian's knowledge. Debian would not know that > the library is still being used, and therefore might autoremove it. > > The impact of this is directly proportional to how many things you > compile yourself, and how important those things are to you. > If you compiled a program yourself, you probably know what its runtime dependencies are. Just create a dummy debian package with the right dependencies (this is a simple two-step task with the "equivs" package installed). Install that package using dpkg -i <package file name> and now Debian knows you don't want those libraries removed. And then you can safely use apt autoremove to keep your system clean.
I'd emphasise that using equivs is *NOT* a big ton of work -- you can very quickly throw together a dummy package even with a decent sized list of dependencies, and decent instructions are only a google away... One thing you might trip over -- when you come to install the dummy package representing your self-built software, if any of the dependencies are not already installed, dpkg -i will fail. Use the -f option to force it to install anyway, then follow up with apt install --fix-broken or aptitude install or whatever to get it to fix the broken dependencies (by installing the missing dependencies, and recognising they are required for the dummy package you installed representing your self-built software). Later, probably *much* later, you might get upgrade problems where the system wants to upgrade those libraries but can't because of the dependcies from your dummy package. The response to that should probably be to recognise that the self-built software may need re-building against the upgraded libraries, to do which you would remove the dummy package, let the upgrade happen, rebuild the self-built package, and then use equivs again to make a new dummy package. The kind of scenario I have in mind here is one where library upgrades change library package names -- I seem to recall fun a while back with with gnome libraries around the time of the upgrade from Gnome 2 to Gnome 3 (Wheezy to Jessie? Or was it earlier?) that had to do with this. The symptom was an attempt to upgrade wanting to remove half the system... At the time I wasn't much of a ninja with apt dependencies, but once I figured out the cause, the solution in that case was just marking libraries as auto-installed that were marked as non-auto and which nothing depended on. That is a different problem but produces a very similar effect to a dummy package depending on libraries whose package names change with an upgrade. I suspect you, Greg, already know a lot of this, but nonetheless hopefully this will be useful for the archives. Mark
