On 2020-04-22 at 16:13, Urs Thuermann wrote: > Debian's package management should remove packages that were > installed automatically, if they are no longer needed. > Unfortunately, that often seems to not work correctly. See this > example on my Raspberry Pi running Raspbian jessie: > > Some time in the past there were probably packages that needed > gcc-4.8-base so it were installed automatically: <snip> > But after many updates/upgrades no installed package needs > gcc-4.8-base anymore but it hasn't been removed. If I check why > it's still installed I get: > > # aptitude why gcc-4.8-base <snip> > That is there is one package (cron) installed that only recommends > one of a list of packages none of which are actually installed. > Then there is a long list of Provides, Recommends, and Depends, all > of which are pointless since the root of all this isn't installed. > At the end of that long list is gcc-4.8-base and that makes aptitude > think it should keep that package? Strange. I don't find 'aptitude why' very reliable in a lot of cases. If you want to know "what's a dependency chain which might have led this to be automatically installed?", or "what's a dependency chain which might give you a reason to want to have this installed?", it's not bad; if you want to know "what's the dependency chain which is keeping this from being safe to remove?", you're probably better off running 'apt-get --dry-run remove [packagename]', and seeing whether the result wants to remove anything that you care about. > Even calling apt-get autoremove explicitly doesn't remove that > package: 'apt-get autoremove' deals only with packages which are marked as auto-installed; for undetermined reasons, some packages which you wouldn't expect to be get marked as manual. 'apt-mark showmanual' will list all packages which are flagged as manually-installed. > # apt-get autoremove > Reading package lists... Done > Building dependency tree > Reading state information... Done > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. > > I regularly observe things like this, not only on Raspbian, but also > on Debian stretch for amd64 which runs on my server machine. One thing I habitually do nowadays, to minimize this type of problem, is to also run # apt-get remove $(deborphan) and interleave that back and forth with 'apt-get autoremove' calls until neither one of them wants to remove anything anymore. deborphan is a program (installed from a package of the same name) which looks for dependency-type packages that aren't depended on by anything else and reports their names. (There's apparently also a frontend program called orphaner, mentioned in the package description, but I've never used it.) This doesn't 100% address the issue, but it will deal with more of it than you might think. Does the 'deborphan' command report gcc-4.8-base, in your case? -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature