Debian's package manager dpkg has the perhaps unique feature that it distinguishes between removing and purging a package. Removing it removes the program files but keeps the configuration files (and sometimes the logs) around, purging it really removes everything. While this distinction undoubtedly has some uses, I have found that I almost never make use of it. I think in about six years of using Debian I have actually needed a remove-but-not-purge functionality about five times, during some really tricky upgrades (and using Aptitude instead of APT might have helped, not sure) and once when I wanted to build a package that had a build dependency that conflicted with a package I had installed (cowbuilder came later).
I think many people don't fully realize this distinction, and thus aged systems will often contain dozens or hundreds of removed-but-not-purged packages lying around. Great fun cleaning that up. And therefore, at some point in the distant past I have switched all my APTs to purge by default, using the configuration setting Apt::Get::Purge "true";. At the time I thought this would be daring, but I have never looked back. The one time a year that I don't want to purge I override this by hand.
Later, APT actually got an apt-get purge command, but there is no apt-get autopurge and no apt-get dist-upgrade-and-purge (or whatever) to purge the packages it wants to remove. This can be worked around by carefully adding --purge to all invocations of apt-get, but who will remember that. And of course apt-get remove is hardwired into my fingers.
How do other people handle this? Are there undiscovered reasons removing is the better default? How do you clean up packages that were forgotten to be purged?
Monday, January 4, 2010
Subscribe to:
Post Comments (Atom)
Posts
aptitude search '~c' to list, and aptitude purge '~c' to remove
ReplyDeleteRemove without purge is a good default because it keeps user data. Anything else is facilitating users shooting their own feet.
ReplyDeleteSomething ugly (that I use and that used to be commonly available on the Internet) to purge the removed packages:
ReplyDeleteCOLUMNS=200 dpkg -l | grep ^rc | awk '{print $2}' | xargs dpkg -P
How do I handle this? I don't. The disk space used is insignificant, even if the chance I'll ever need an old config file is pretty small.
ReplyDeleteIn interactive aptitude:
ReplyDeletelimiting view to configured pacakge:
l ~c
the you can purge them all with _
Once in a while I run synaptic and mark all packages with status "Not installed (residual config)" for Complete Removal.
ReplyDeletePurging by default really calls for troubles. The obvious example is a dist-upgrade that requires the temporary removal of some package that you actually need. While this might be unlikely in stable, it happened to me quite a few times on my testing/unstable systems.
ReplyDeleteBetter do some regular cleanups - e.g. you might also want to remove packages that are fully installed but do not exist in anymore in any repository.
I use aptitude remove --purge most of the time, and I periodically do what the first anon said to list and purge old leftovers. I also have etckeeper if I need to rewind some conffiles. Purge by default is still asking for trouble.
ReplyDeleteI meant aptitude purge --purge-unused, not remove --purge. And aptitude lets me review what will happen before confirming.
ReplyDeleteI always use aptitude now, now apt-get. I got completely used to hitting "_" in the UI instead of "-".
ReplyDeleteTo find packages that were left unpurged by some accident, I do this:
dpkg --list '*' | egrep -v '^(ii|[up]n)'
> This can be worked around by carefully adding --purge to all invocations of apt-get, but who will remember that.
ReplyDeletealias apt-get='apt-get --purge'
Good idea. Normally, you would need to put that into root's shell initialization, which might add another level of indirection and complication for some people.
ReplyDelete