Your message dated Thu, 1 Oct 2015 23:45:24 +0100
with message-id <[email protected]>
and subject line Re: [Aptitude-devel] Bug#661188: aptitude purge <package>
recursively REMOVES BUT DOES NOT PURGE the unneeded dependencies of <package>
has caused the Debian Bug report #661188,
regarding aptitude: recursive remove (like "pacman -Rs")
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
661188: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661188
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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:
georgiy@PANTHER:~$ su
Password:
root@PANTHER:/home/georgiy# aptitude install byobu
The following NEW packages will be installed:
byobu python-newt{a}
0 packages upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/150 kB of archives. After unpacking 995 kB will be used.
Do you want to continue? [Y/n/?] y
Preconfiguring packages ...
Selecting previously deselected package python-newt.
(Reading database ... 155478 files and directories currently installed.)
Unpacking python-newt (from .../python-newt_0.52.11-1_amd64.deb) ...
Selecting previously deselected package byobu.
Unpacking byobu (from .../byobu_2.80-1+squeeze1_all.deb) ...
Processing triggers for man-db ...
Processing triggers for desktop-file-utils ...
Processing triggers for gnome-menus ...
Setting up python-newt (0.52.11-1) ...
Processing triggers for python-central ...
Setting up byobu (2.80-1+squeeze1) ...
root@PANTHER:/home/georgiy# # NOTICE HERE HOW python-newt IS REMOVED BUT
NOT PURGED
root@PANTHER:/home/georgiy# aptitude purge byobuThe following packages will
be REMOVED:
byobu{p} python-newt{u}
0 packages upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 995 kB will be freed.
Do you want to continue? [Y/n/?] y
(Reading database ... 155600 files and directories currently installed.)
Removing byobu ...
Purging configuration files for byobu ...
Processing triggers for desktop-file-utils ...
Processing triggers for gnome-menus ...
Processing triggers for man-db ...
(Reading database ... 155490 files and directories currently installed.)
Removing python-newt ...
root@PANTHER:/home/georgiy# aptitude install byobu
The following NEW packages will be installed:
byobu python-newt{a}
0 packages upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/150 kB of archives. After unpacking 995 kB will be used.
Do you want to continue? [Y/n/?] y
Preconfiguring packages ...
Selecting previously deselected package python-newt.
(Reading database ... 155478 files and directories currently installed.)
Unpacking python-newt (from .../python-newt_0.52.11-1_amd64.deb) ...
Selecting previously deselected package byobu.
Unpacking byobu (from .../byobu_2.80-1+squeeze1_all.deb) ...
Processing triggers for man-db ...
Processing triggers for desktop-file-utils ...
Processing triggers for gnome-menus ...
Setting up python-newt (0.52.11-1) ...
Processing triggers for python-central ...
Setting up byobu (2.80-1+squeeze1) ...
root@PANTHER:/home/georgiy# # NOW NOTICE HOW PASSING --purge TO purge HAS
THE CORRECT BEHAVIOR OF PURGING AS WELL AS REMOVING python-newt
root@PANTHER:/home/georgiy# aptitude purge --purge byobuThe following
packages will be REMOVED:
byobu{p} python-newt{pu}
0 packages upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 995 kB will be freed.
Do you want to continue? [Y/n/?] y
(Reading database ... 155600 files and directories currently installed.)
Removing byobu ...
Purging configuration files for byobu ...
Removing python-newt ...
Processing triggers for desktop-file-utils ...
Processing triggers for gnome-menus ...
Processing triggers for man-db ...
root@PANTHER:/home/georgiy#
--- End Message ---
--- Begin Message ---
Hi Georgiy,
2012-02-28 04:26 Georgiy Treyvus:
@Daniel:
One thing I think that can be done is to modify the documentation to be
clearer about these things so that there are no surprises.
As for the issue of "aptitude purge evolution" lopping off half the system
yes I understand the price of the convenience of metapackages. The
documentation should warn people about that issue so there are no
surprises. So long as people know that the desktop components were
installed via the gnome package they'll understand what's safe and unsafe
to do. But frankly this behavior is also good in the sense that it lets you
cleanly install and remove and jump between entire desktop environments
instead of painfully removing and installing a bunch of components. If you
do want specific pieces of a desktop install simply install/remove those
components. Once you know the deal it's all good.
Things can however be made more flexible/convenient with package groups.
Just out of curiosity does APT have the notion of package groups because I
know that Pacman does? Read this to help clarify if needed.
https://wiki.archlinux.org/index.php/KDE_Packages
Maybe adding the concept of package groups to APT would help people.
Another thing is that maybe in the tasksel portion of the installer people
should be asked whether they want the desktop as a metapackage or a package
group? In all fairness this shouldn't be present in the automated install
so as not to confuse n00bs but perhaps in the normal/advanced install it
should be present. I have plenty of disk space but I'd love a clean
headache free way of removing evolution, epiphany, etc...
As the wiki page discusses, there are advantages and disadvantages to
software groups, like being only useful at the time of installing it,
but not getting new packages as the KDE software collection evolves
(e.g. recommending a new browser, mail client, media player, or core
components) and as new Debian and KDE releases come out.
Similar results to groups are usually achievable in Debian by choosing
different "levels" of meta-packages, like "kde-standard" and "kde-full",
which kind of solve the problem with both groups and meta-packages as
discussed in that wiki page (Arch also uses this).
Another way is with different levels of dependencies: gnome Depends on
evolution, but mate-desktop-environment merely suggests that.
In any case, this is not the best place to discuss features that could
be added to APT.
Speaking of the automated install it should not be in the advanced section
of the installation disk and should be more visible to n00bs...
That's again a topic where this is not the best place to discuss.
Also though I understand your reasoning for the behavior of "aptitude
remove <package>" and "aptitude purge <package>" I really think remove
should remove recursively and purge should purge recursively. That's how it
works in Pacman when you add the -n or --nosave option.
http://www.archlinux.org/pacman/pacman.8.html
Also further experimentation has shown that
"aptitude remove <package>" == "apt-get remove <package> && apt-get
autoremove"
"aptitude purge <package>" == "apt-get purge <package> && apt-get
autoremove"
This equivalence is exact for say you have package A depending on B and C.
Say you have package D depending on E and F. Say you go:
aptitude install A D
apt-get remove A
B and C are still installed. Now say you go:
aptitude remove d
Not only are E and F removed as is expected by aptitude's recursive nature
but B and C are also. This unlike pacman's "pacman -Rs d" which will remove
e and f, but leave b and c untouched unless they are:
1. explicitly removed with "pacman -R B C"
2. removed by "pacman -Rs A" which will still work in spite of A being gone
3. by having "pacman -Ru" invoked. The -u option tells pacman to remove
orphaned packages making "pacman -Ru" the exact equivalent of "apt-get
autoremove". -Run == autopurge.
This isn't just a theory. I wrote the testAptitude.sh script that's
attached and redirected the output to the testAptitudeOutput.txt. The
latter is verbose but very illuminating in terms of proving what I said.
I am not sure what's your point here, the script proves what you said
and at the same time how these tools are designed to work.
apt doesn't remove unused packages proactively, it offers you to do so
if you want; but aptitude does, and users request and complain if
packages are not removed immediately (even when it can be dangerous),
because they value highly not having cruft (there are many bug reports
about this still open, in the case that you want to confirm it).
Even then, aptitude is not completely reckless -- it informs you when
unused packages are going to be removed and you can cancel those
actions, and the fact that they are not purged right away (what sparked
the initial complaint of this report) allows you to reinstall and have
the configuration from before, if you did it by mistake or want to get
back for some reason.
The fact that these tools don't work in the same way as pacman does is a
bit immaterial, since they predate pacman by many years, and in fact
they raised the standard enormously when they where introduced (to the
point that it was copied and ported even to other operating systems, and
most GNU/Linux distributions use tools with similar concepts and
features now).
And the fact that many people are by now used to how apt and aptitude
work for the best part of 2 decades, makes that changing it to behave
like pacman is not a good idea. Neither pacman nor apt nor aptitude are
clearly superior, they simply have a different approach about how to
address these issues.
It would be nice if APT had a clean way of removing, removing recursively,
purging, purging recursively, any given package. And of course a separate
pacman -Ru type thing for cleaning up any messes which may possibly be left
over.
APT is not bad especially in comparison to the disgrace we call yum.
However there is room for more consistent predictable behavior and
pacmanesque improvements.
Again, that's a feature request for apt, not for aptitude.
Lastly, from Axel:
2012-02-25 08:19 Axel Beckert:
Hi,
Georgiy Treyvus wrote:
The problem is exactly what the subject line suggests.
This is a feature, not a bug. It would be a bug if it would also purge
the unneeded dependencies.
There could be an option to enforce this, but the default should be
never to also purge the dependencies.
I agree that this is a feature. (As explained in previous messages,
there's an option to do that nevertheless, aptitude::Purge-Unused, but
off by default; or equivalent of adding --purge-unused in the command
line).
If one purges recursively the (unused) dependencies, which might happen
by mistake, and those dependencies include things like carefully crafted
mail or web server configurations, it's an error from which one cannot
easily recover (other than backups, but even then it's not very quick).
In comparison with that scenario, forcing to purge a package that was
"only removed" (with config files around, if the package has any) is
much less of a hassle.
So in summary, after the long discussions in this bug report, there are
not many actionable items for aptitude in this bug report other than
implementing the recursive purging (subject below):
Subject: aptitude purge <package> recursively REMOVES BUT DOES NOT
PURGE the unneeded dependencies of <package>
and as explained, the recursive purging is easily achievable with either
--purge-unused or setting the configuration option
aptitude::Purge-Unused if one wants it to behave in the same way all of
the time.
So I am going to close this bug report now, since there is nothing left
to do.
Cheers.
--
Manuel A. Fernandez Montecelo <[email protected]>
--- End Message ---
_______________________________________________
Aptitude-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
