Charlie wrote: > In a different email, under the heading: Re: Installing an Alternative > Init? Andrei posted this in part: > > [quote] A package not properly cleaning after itself on purge is > generally considered a bug in Debian, severity depending on the impact, > of course. [end quote] > > I suppose this is literal, just that package? Yes. Just that package. Not the package dependencies. Because there is the APT "autoremove" functionality for that purpose. > Because I have install a package which also pulled in some > dependencies. > > Upon purging it, because it didn't suit the purpose of what I wanted to > do. It purged itself, but left the dependencies on the system. That is expected. Because when you purged that package the tool doesn't know if you were going to install an alternative tool or a different version of that tool or something different. It shouldn't remove the dependencies recursively. Again there are other tools for doing recursive removals. See "orphaner" in the 'deborphan' package for example. Although I think "apt-get autoremove --purge" is the main example these days. > I can only suppose this is what is supposed to happen? I backtracked and > found them, purging each in turn. > > I also suppose this is what's supposed to happen? > > Or is there some command using apt-get that allows me to purge a > package and the dependencies it pulled in as well? That or run this: apt-get autoremove --purge The above is my normal course of action. > Just curious and trying to learn a bit more. Read the man page for apt-mark for more information about how this works. That command is relatively new in Wheezy. Previously there was some of the functionality (hold/install) directly in dpkg. That plus whether a package was installed manually or installed as a dependency has had an interface to that information made available through the apt-mark command. You can see the list of packages automatically installed with "apt-mark showauto". You can directly manipulate the state using that command too. The idea is that if the package that pulled in packages is removed then you can run apt-get autoremove to remove the dependencies too. It is up to you to know that if you want them purged you can add the --purge option. I have good backups plus I use etckeeper so I am confident of simply purging /etc files and therefore mostly purge packages. That avoids a lot of interaction bugs such as some of the well known problems with PHP having config to load libraries that have been removed. If it were purged then the config would have been removed too and no problem would have been noticed. That is just one example. Therefore it is good to keep the system clean of "rc" state things. The deborphan command can help there too. dpkg -l | grep ^rc On my Sid system it is this daily routine: apt-get update && apt-get dist-upgrade -d -y # in /etc/cron.daily apt-get upgrade apt-get dist-upgrade apt-get autoremove --purge apt-get clean reportbug packagefoo At the dist-upgrade and autoremove steps I carefully inspect the list and say No and adjust things with "hold" as needed. After upgrade and reportbug it is often necessary to downgrade to the previous version still in Testing. apt-cache policy packagefoo apt-get install packagefoo=1.2.3-4 Bob
Attachment:
signature.asc
Description: Digital signature