software-center and remove vs. purge

Michael Vogt mvo at
Tue Dec 7 09:13:50 GMT 2010


I recently came accross the following idea that
discusses remove vs purge in softare-center:
and I would like to discuss it here.

Let me briefly recap the difference between the two. The "removal"
means that the content of the package gets removed from the
filesystem. With "purge" the package content *and* the system config
files (usually in /etc) will get removed as well. Some package will
also do additional removal (like removing the mythtv-database content
when purging mythtv-database leading to people losing data).

This is not a easy problem and we need to carefully balance the needs
to keep the UI simple with the needs to keep the system from
accumulating cruft. There are good suggestions in the brainstorm
entry. I think that while in 99(,9 probably)% of all cases a purge is
fine the cost for the error in the remaining cases can be pretty high
(consider someone spending a lot of time tweaking their
squid.conf). So software-center errs on the safe side and defaults to
remove currently.

Its difficult to tell programmatically what is going to happen when
the maintainer script is called with "purge" as this is a shell
script. Our tools can estimate what amount of data the configuration
file was using (and even if the user ever modified it or not) but not
what additional steps the maintainer script will take (unless of
course there is not maintainer script or no purge target in it :)

That being said I think we should make it easy for the user to access
the purge functionality both inside software-center and
computer-janitor. For software-center I would like to add a option
(File/Remove with configuration). A alternative solution would be to
make purge the default and have a option "File/Remove but preserve the
configuration). What do you think about what the default should be?
For most packages "purge" will be fine, its just the few ones where it
isn't that I'm concerned about.

For computer-janitor a plugin for packages that are removed but not
purged sounds appropriate. Combined with some intelligence about
detecting cases that a purge is harmless (like checking for "purge" as
a target on postrm and checking if the configuration file was actually
modified) we should get most packages right. With additional data like
looking at what date the package was removed we can get the remaining
ones right (i.e. if it was removed 3 month ago it probably is not
missed by the user).


More information about the ubuntu-desktop mailing list