[Aptitude-devel] Bug#716992: Bug#716992: aptitude does not purge deleted packages when it asks for user confirmation

[Manuel A. Fernandez Montecelo]

retitle 716992 aptitude: No way to purge auto-removed packages (implement a new config option to always purge deleted packages?)
tags -1 + moreinfo
stop


Hi all,

Since all these bug reports were merged, only the oldest one is visible
from the overall list.  The assumptions/information of some of the
reports are a bit wrong/misleading about the real problem, so making a
note about this in all bug reports and retitling so it's more clear.


2013-07-16 18:16 Uwe Storbeck:
>
>> Presently there is no option to do what you ask, which is beyond the
>> scope of Purge-Unused.  Responding to those prompts where “remove this
>> package to resolve a conflict” is not the same as removing an unused
>> package.
>
>It would be nice to have a more general purge option which
>would change the behavior of aptitude to always purge config
>files when a package gets deleted, no matter why it is deleted.

Indeed, the reason why the packages are not purged in these reports,
despite Purge-Unused enabled, is because internally aptitude doesn't
classify them as "removed because unused", but "auto-removed to solve
some conflict/problem".

That is why in the aptitude in the different reports shows for example
"lpr{a}": {a} is for auto-removed, while it would be empty for remove,
{p} or {up} (unused - purge) otherwise.


Trying to second-guess, I think that what you reporters are after by
using Purge-Unused is not just purge unused packages, but actually "do
not simply remove, NUKE ALL TRACE OF THE REMOVED PACKAGES OUT OF MY
SYSTEM".  So I am not sure if Purge-Unused is very useful as it is.

It shouldn't happen though that we start to treat this option to also
purge auto-removed packages because of conflicts.  Many unused packages
are libraries with new SONAMES, or packages that change name for other
reasons (and maybe auto-migrate config), or packages that were pulled
automatically and the user was never particularly interested in.

Packages removed because of conflicts are different, specially using
testing and unstable, because maybe they conflict due to problems with
transitions, and they can include manually installed packages.  Maybe
the users accept to remove the conflicting package because they are
interested in upgrading, and they don't need the package to be
auto-removed for a while, and then can install again when needed -- so
they don't mind to accept that solution temporarily.  But purging the
data/config in those cases is not nice.

So probably the best/only solution to have this done all the time is
what Uwe says, to create another config option to always purge, rather
than simply remove, packages deleted from the system.


What is not clear to me yet is if then all the people who already have
Purge-Unused enabled would want to migrate to the new option, or if some
would genuinely be interested in just using Purge-Unused -- because as
these reports suggest, in the eye of the user there does not seem to be
a clear distinction.

In a way, providing both options would be the easiest solution in the
short term, but I am concerned about the proliferation of options,
specially when they overlap/interact -- they tend to be messy in the
code, cause bugs in corner cases, get forgotten in some other cases, and
in general complicating the life of developers and users in the long
term.  Case in point: quiet and verbose; Delete-Unused + Purge-Unused
(which is forgotten in some cases, apart from the particular case of
this bug report), or the different options like RecommentsImportant /
SuggestsImportant and their different incarnations in both apt and
aptitude.


So I am leaving this to rest for a while for further consideration.


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>