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

Georgiy Treyvus georgiytreyvus at gmail.com
Sat Feb 25 03:12:44 UTC 2012


Firstly sorry if it was too long. The relevant parts were:


root at PANTHER:/home/georgiy# # NOTICE HERE HOW python-newt IS REMOVED BUT
NOT PURGED
root at PANTHER:/home/georgiy# aptitude purge byobu
The following packages will be REMOVED:
  byobu{p} python-newt{u}
...
root at PANTHER:/home/georgiy# # NOW NOTICE HOW PASSING --purge TO purge HAS
THE CORRECT BEHAVIOR OF PURGING AS WELL AS REMOVING python-newt
root at PANTHER:/home/georgiy# aptitude purge --purge byobu
The following packages will be REMOVED:
  byobu{p} python-newt{pu}
...

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?

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...

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.

With that said while I understand the safety rationale for the current
behavior I still feel it causes more harm then good. 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/

On Fri, Feb 24, 2012 at 9:15 PM, Daniel Hartwig <mandyke at gmail.com> wrote:

> Hello
>
> On 25 February 2012 05:32, Georgiy Treyvus <georgiytreyvus at gmail.com>
> wrote:
> > package: aptitude
> > version: 0.6.3
> >
> > The problem is exactly what the subject line suggests. There is a simple
> > workaround of passing --purge to aptitude purge but that looks and feels
> > ridiculous. Anyway let my terminal do the talking:
> >
>
> TL;DR -- this "simple workaround" is actually a safety measure to
> prevent accidental data loss.
>
>
> Purging packages removes files that contain potentially useful
> data--logs, conffiles, etc..  Unless the user explicitly asks for a
> package to be purged then it will only be removed.  This is intended
> to protect user data from being accidentally destroyed.
>
> On the command-line "aptitude purge byobu" the only explicitly
> requested package is byobu, so that is the only one purged.
>
> Note that apt-get behaives similarly, where "apt-get remove foo" does
> not even remove unused packages and "apt-get autoremove" also requires
> "--purge".
>
> If you *always* desire unused packages to be purged:
>
> -- /etc/apt/apt.conf
> Aptitude::Purge-Unused "true";
> --
>
> and this will be the default.  *User beware*.
>
>
> In your example, perhaps I have customized the configuration of the
> auto-installed package python-newt and wish to continue using it in
> the future.  If Purge-Unused was the default then when byobu is
> purged so too is python-newt, and along with it the customizations
> performed to it's configuration (not too mention log data).
>
> A savy user will pick up on this and cancel the operation, mark
> python-newt as manually installed, and redo--however, aptitude must be
> relatively safe for non-savy users as well.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/aptitude-devel/attachments/20120224/7c63ca49/attachment.html>


More information about the Aptitude-devel mailing list