[Aptitude-devel] Bug#661188: aptitude purge <package> recursively REMOVES BUT DOES NOT PURGE the unneeded dependencies of <package>

Daniel Hartwig mandyke at gmail.com
Mon Feb 27 06:16:25 UTC 2012


On 25 February 2012 11:12, Georgiy Treyvus <georgiytreyvus at gmail.com> wrote:
> Firstly sorry if it was too long. The relevant parts were:
>

Not at all.  Please do include more information with bug reports
rather than less :-)

>
> Question: To be clear when if I tweak Aptitude::Purge-Unused to true it
> effects only "aptitude purge <package>" and not "aptitude <remove> package"
> correct?
>

No.  Purge-Unused will cause unused packages to be purged regardless
of whether you use "purge" or "remove" on the command-line.

With this option set "aptitude remove foo" will only remove foo, but
any unused packages will be purged.  The same is true in the curses
interface: aptitude will still respect remove or purge for packages
you explicitly mark, however, auto-removed packages will be purged
with Purge-Unused, or only removed without it.


Purge-Unused ("--purge-unused") is *not* equivalent to:

# apt-get remove --purge foo

but rather:

# apt-get autoremove --purge

The first command does not act on unused dependencies.


> Also while you say that the current behavior is a safeguard and I do agree
> partially the current behavior will also confuse new users. At some point in
> time much like me they're reading the documentation, they learn to use
> remove in case they wish to reinstall the package and keep current
> configuration, they learn to use purge if they want it gone period or if
> they want a fresh start for whatever reason.
>
> Say they go "aptitude purge <package>" wanting to then install with a fresh
> start. The messed up conf file belonging to some dependency isn't removed.
> After purging they install again, it's not how they remembered it to be at
> first, confusion ensues...
>

What about a misconfigured dependency that is kept because other
packages depend on it?  The user may be just as unaware of this other
depending package and be just as confused that configuration is not
restored.

Generally, if the user chooses to correct configuration files this way
then they must become aware of precisely which packages are
misconfigured and target them specifically.  This problem is not
thoroghly resolved by the proposed behaviour for "purge" to autopurge
dependencies also.


> The way the documentation is worded users will understand the consequences
> of purge. They think remove means keep configuration just in case and purge
> means clean it I want a fresh start. Yet aptitude behaves differently then
> described. Many simply may not figure out what's happening in such a
> situation.
>

IMO the documentation in this area can easily be understood both ways
(possibly more).  Where exactly have you gotten the impression that
"aptitude purge <package>" also applies "purge" to unused
dependencies?

In the man page, there is only one description of what a purge is:

           <package>_
               Purge <package>: remove it and all its associated configuration
               and data files.

Several descriptions of a "purge" in the user manual are equivalent to
this in that they say nothing about what becomes of the unused
dependencies.

The documentation for Delete-Unused and Purge-Unused does clearly
describe the current behaviour when each is set.


> With that said while I understand the safety rationale for the current
> behavior I still feel it causes more harm then good.

Indeed.  Given that it is reasonable for a user to expect either extreme, or
something in between, then the safest course is most appropriate.

A more informed user can get the behaviour they desire with some option
setting and a less informed user is not subject to potential data loss.


> Speaking of keeping
> aptitude safe for new users here is an interesting issue to look into that
> has caused many a n00b grief http://tanguy.ortolo.eu/blog/article8/
>

I was struck by this same issue myself way-back-when.  Picked up on it as
the list of to-be-removed packages contained many unexpected items.

It is fundamental to the use of meta-packages for that purpose and not
particularily specific to aptitude.. though I could be mistaken here ;-)





More information about the Aptitude-devel mailing list