The Wanderer <wande...@fastmail.fm> writes: > 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.
Well, I usually just call aptitude purge without --simulate because I want unneeded packages to be really removed and aptitude asks for confirmation if it would need to remove more packages. Here, with -s, but you can see that gcc-4.8-base is really not needed by anything. # aptitude remove -s gcc-4.8-base The following packages will be REMOVED: gcc-4.8-base 0 packages upgraded, 0 newly installed, 1 to remove and 0 not upgraded. Need to get 0 B of archives. After unpacking 176 kB will be freed. Would download/install/remove packages. > '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. But as I showed in my first mail, gcc-4.8-base *is* auto-installed: # apt-mark showmanual | grep gcc # Despite this, apt-get autoremove doesn't remove it. > 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. That also doesn't help: # 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. # deborphan raspi-copies-and-fills BTW, this also is strange since raspi-copies-and-fills is *not* auto-installed: # apt-mark showmanual | grep raspi raspi-copies-and-fills That's why from time to time I look through the whole list of installed packages that look suspicious, i.e. auto-installed packages, especially with names matching lib*, *-common, and *-base, and that have multiple instances installed of the same name differing only in version. It seems there is no other reliable way to get rid of some old stuff :-( > 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? No, as shown above. urs
