I have always used aptitude very simply from the command line to update, upgrade, remove and purge packages.

I wanted to remove cherokee and start again with it so I did:

and

One of those commands (can't remember which) said it couldn't remove a directory (think it was /etc/cherokee) because it wasn't empty, which I thought a bit odd.

So I did:

and found a whole bunch of cherokee files and folders in various places in the system. I've looked at the man page for aptitude and as far as I can make out, "remove" and "purge" should do what I want. That is, completely remove from the sytem, all traces of cherokee or any other package.

Am I misunderstanding something here or is there something else I need to be doing to uninstall a package?

Cheers.

That message is quite normal. aptitude will always warn you about non-empty folders and will leave them alone. If you're sure there's nothing of value in the /etc/cherokee folder you can try emptying it manually (maybe make a backup of it just to be safe) and run the purge command again. That should wipe out the /etc/cheroke [now empty] folder. If nothing bad happens for a day or two, you can then delete the backup you made.
cheers,
jdk

I've made a copy of all the cherokee folders and files I found and then deleted them by hand; purge didn't do it.

My main question is: why doesn't aptitude do it when I ask it to? Is there something else I should be doing or understanding to make it work as expected?

I think it is possible for more than one package to use the same folder or else some folders may be manually altered for various reasons. aptitude seems to want to err on the side of caution. It informs you of the state of affairs (this folder is not empty) and then lets you decide what to do about it.
Cheers,
jdk

It doesn't do what you ask it to because you aren't asking it to do what you think you are. When you read the word 'purge', you think it means "remove everything - including non-empty folders related to this application." But aptitude is not built to do that. As Jdkaye explained, aptitude errs on the side of caution. You can file a wishlist bug, if you would prefer it to work a different way (perhaps request an 'uber-purge' command), but as things stand, this is what it does. (I agree that the aptitude manual might be a bit clearer about what 'purge' will or won't remove.)

offtopic: is there allready a liscence on that sentence? :-), that gave me a bit to think about. greetings.

Well, I guess it's a good thing in general to be cautious and I've noticed this behaviour before. In this instance, aptitude left pretty much everything in place. For example, single files in /usr/lib and /var/lib/dpkg/info and folders and files in /usr/share. Aptitude (can't remember if it was the remove or purge command) only told me about the folder in /etc though; I had to manually find all the other stuff.

Although I have installed quite a few packages from source and the odd .deb package installed with dpkg, cherokee was installed with aptitude and I kind of expected it to be cleanly uninstalled. Maybe letting aptitude have it's way and then do a hunt-and-delete operation is the way to go, although doing that could have it's problems too.

Oh well, guess I'll just keep expanding the size of /.



Thanks.

try:
(first shows whats left over, second purges it, before ~c is free space)
greetings

That is exactly what I thought, with one proviso. That 'purge', would remove everything related to a particular application that 'remove' had left behind, as long as no other program depends on those items being in place. If aptitude does not do that, then it seems to me that there is no way to automatically and safely uninstall a program and its related files and folders. An 'uber-purge' (ie. don't check, just delete this stuff) command would be fine in the case of cherokee (or any other program and its related files and folders that nothing else depends on) because I don't think that anything else depends on its related files and folders being there, but such a command would still really need to check for dependancies or it would sometimes break things.

Hang on, that's what I think 'purge' should do. But it seems then, that it doesn't. Clearly it does do some form of checking, but perhaps only to the extent of:

Oh, 'remove' has left some stuff behind so I'll leave it alone too.

Maybe it's just too difficult to check everything like that; I don't know. Hmm...

Cheers.

That seems like it might work but when I do:

it does not find the cherokee files I left in /usr/share/doc and only one file of the several that are in /var/cache/apt/archives.

Maybe it would have found more if I hadn't already removed then manually. I will try that next time I want to uninstall something.

Cheers.

did you also try exactly
? greetings

FIles created by package = { fixed files , conf files, files created during runtime }
As somebody said, folders may contain files from other packages. If only files from cherokee were in this directory and a apt-get remove did not remove {fixed files,files created during runtime} then it's a BUG in cherokee (similar to this)
Purge also removed conf files. You can get a list of configuration files with dpkg -s packagename and look at "conffiles"

You can probably create a bug report.

Or do you have problems with other packages, like your title says?

Yes, What is the purpose of the command?

It listed over 100 files but only one of them was related to cherokee.

That is the same file that is listed when I did

Ok, thanks for that. I'll install and remove - purge cherokee again and monitor what happens.

Yes, I think I've noticed this before with other packages but those instances may have been examples of aptitude working as it should, ie. folders may have contained files from other packages. If it happens again I will investigate the situation to determine what is going on.

Cheers.

(A good reference for Aptitude's search terms.) The search parameter ~c So, you have 100 packages that were removed but not purged. If you want to do something about that, you can also use it in commands like this:
When I want to purge things, I often do this As I recall, aptitude purges the package foobar (as you ask it to), but it only removes foobar's dependencies. So if you want to recursively purge something (ie, purge it and purge its dependencies), you need to run aptitude purge ~c afterwards to catch the items that were removed but not purged. Perhaps that's (part of?) what happened to you?