<div>@Shirish:</div><div>Maybe I'm just stupid, but I don't quite understand what you're trying to say here. I realize English is not your native language but can you explain your point more clearly? </div><div>
<br></div>@Daniel:<div><br></div><div>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.</div><div><br></div><div>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.</div>
<div><br></div><div>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. <a href="https://wiki.archlinux.org/index.php/KDE_Packages" target="_blank">https://wiki.archlinux.org/index.php/KDE_Packages</a></div>
<div><br></div><div>Maybe adding the concept of package groups to APT would help people.</div><div><br></div><div>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...</div>
<div><br></div><div>Speaking of the automated install it should not be in the advanced section of the installation disk and should be more visible to n00bs...</div><div><div><div><div><br></div><div>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. <a href="http://www.archlinux.org/pacman/pacman.8.html">http://www.archlinux.org/pacman/pacman.8.html</a></div>
<div><br></div><div>Also further experimentation has shown that</div><div>"aptitude remove <package>" == "apt-get remove <package> && apt-get autoremove"</div><div>"aptitude purge <package>" == "apt-get purge <package> && apt-get autoremove"</div>
<div><br></div><div>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:</div><div><br></div><div>aptitude install A D</div><div>apt-get remove A</div>
<div><br></div><div>B and C are still installed. Now say you go:</div><div><br></div><div>aptitude remove d</div><div><br></div><div>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:</div>
<div>1. explicitly removed with "pacman -R B C"</div><div>2. removed by "pacman -Rs A" which will still work in spite of A being gone</div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><div class="gmail_quote"><br></div><div class="gmail_quote">2012/2/27 shirish शिरीष <span dir="ltr"><<a href="mailto:shirishag75@gmail.com" target="_blank">shirishag75@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">some additions :-<br>
<br>
2012/2/27 shirish शिरीष <<a href="mailto:shirishag75@gmail.com" target="_blank">shirishag75@gmail.com</a>>:<br>
<div>> I too have been bitten by this in the past and do think what Daniel<br>
> has given as an answer is okish (although there should be some sort of<br>
> better way.) For my exchange see [0] . One of the things which I<br>
> didn't know to figure out how to produce a listing of such packages<br>
> using aptitude [1] which was shared by Daniel as well. As I have<br>
</div> purged all the packages which were removed haven't been able to test<br>
out if dpkg -L (2) works on such packages as well or not. George if you<br>
<div><div>> have some packages whose configuration files are still it would be<br>
> nice if you could produce a listing of what you get. If you do get the<br>
> location of those files then a user could attempt at least to know<br>
> what they contain and perhaps judge (or not) whether it could be<br>
> useful now or latter.<br>
><br>
> Another point to be kept at back of mind as well is over a period of<br>
> time a package could merge other packages in it or be split in one or<br>
> more packages, in the former the config files remaining the same<br>
> (while binary is removed) while at the latter more config files would<br>
> perhaps be added.<br>
><br>
> I have a very vague sense of how aptitude does things so I might be<br>
> right (or not).<br>
><br>
> I do hope however that my $0.02 does prove to be useful to you<br>
> otherwise simply disregard it.<br>
><br>
> 0 - <a href="http://lists.alioth.debian.org/pipermail/aptitude-devel/2012-February/001945.html" target="_blank">http://lists.alioth.debian.org/pipermail/aptitude-devel/2012-February/001945.html</a><br>
> 1 - aptitude search ?config-files<br>
> 2 - dpkg -L = -L|--listfiles <package> ... List files `owned' by package(s).<br>
><br>
> A healthy package displays something like this , a random e.g. :-<br>
><br>
> $ dpkg -L fonts-gubbi<br>
> /.<br>
> /etc<br>
> /etc/fonts<br>
> /etc/fonts/conf.avail<br>
> /etc/fonts/conf.avail/65-0-fonts-gubbi.conf<br>
> /etc/fonts/conf.d<br>
> /usr<br>
> /usr/share<br>
> /usr/share/doc<br>
> /usr/share/doc/fonts-gubbi<br>
> /usr/share/doc/fonts-gubbi/changelog.gz<br>
> /usr/share/doc/fonts-gubbi/changelog.Debian.gz<br>
> /usr/share/doc/fonts-gubbi/copyright<br>
> /usr/share/fonts<br>
> /usr/share/fonts/truetype<br>
> /usr/share/fonts/truetype/Gubbi<br>
> /usr/share/fonts/truetype/Gubbi/Gubbi.ttf<br>
> /etc/fonts/conf.d/65-0-fonts-gubbi.conf<br>
><br>
<br>
<br>
</div></div>I did try it just now with a library which I know is no longer needed<br>
(although aptitude hasn't removed/purged it). This is on a Debian sid<br>
machine.<br>
<br>
$ aptitude search libgs?<br>
p libgs-dev - interpreter<br>
for the PostScript language and for PDF - Develop<br>
v libgs-esp-dev -<br>
i libgs8 - The<br>
Ghostscript PostScript/PDF interpreter Library<br>
i A libgs9 - interpreter<br>
for the PostScript language and for PDF - Library<br>
i A libgs9-common - interpreter<br>
for the PostScript language and for PDF - common<br>
<br>
Just extracted partial listing. It seems aptitude doesn't respect the<br>
wildcard '?' as it produces a whole listing but that I guess is<br>
another issue.<br>
<br>
See libgs8 :-<br>
<br>
$ aptitude show libgs8<br>
Package: libgs8<br>
State: installed<br>
Version: 8.71~dfsg2-9<br>
Priority: optional<br>
Section: libs<br>
Maintainer: Debian Printing Team <<a href="mailto:debian-printing@lists.debian.org" target="_blank">debian-printing@lists.debian.org</a>><br>
Uncompressed Size: 16.2 M<br>
Depends: libc6 (>= 2.7), libcomerr2 (>= 1.01), libcups2 (>= 1.4.0),<br>
libcupsimage2 (>= 1.4.0), libfontconfig1 (>=<br>
2.8.0), libgcrypt11 (>= 1.4.2), libgnutls26 (>= 2.7.14-0),<br>
libgssapi-krb5-2 (>= 1.6.dfsg.2), libjasper1 (>=<br>
1.900.1), libjbig2dec0, libjpeg62 (>= 6b1), libk5crypto3 (>=<br>
1.6.dfsg.2), libkrb5-3 (>= 1.6.dfsg.2),<br>
libpaper1, libpng12-0 (>= 1.2.13-4), libstdc++6 (>= 4.1.1),<br>
libtiff4, zlib1g (>= 1:1.1.4)<br>
Breaks: ghostscript (< 8.71~dfsg2-7)<br>
Replaces: ghostscript (< 8.71~dfsg2-7)<br>
Description: The Ghostscript PostScript/PDF interpreter Library<br>
Ghostscript is used for PostScript/PDF preview and printing. Usually<br>
as a back-end to a program such as ghostview, it<br>
can display PostScript and PDF documents in an X11 environment.<br>
<br>
This package provides the Ghostscript library which makes the<br>
facilities of Ghostscript available to applications.<br>
Homepage: <a href="http://www.ghostscript.com/" target="_blank">http://www.ghostscript.com/</a><br>
<br>
Tags: implemented-in::c, role::shared-lib, use::printing,<br>
use::viewing, works-with-format::pdf,<br>
works-with-format::postscript<br>
<br>
Looking at libgs9 now :-<br>
<br>
$ aptitude show libgs9<br>
Package: libgs9<br>
State: installed<br>
Automatically installed: yes<br>
Version: 9.05~dfsg-2<br>
Priority: optional<br>
Section: libs<br>
Maintainer: Debian Printing Team <<a href="mailto:debian-printing@lists.debian.org" target="_blank">debian-printing@lists.debian.org</a>><br>
Uncompressed Size: 10.4 M<br>
Depends: libc6 (>= 2.7), libcomerr2 (>= 1.01), libcups2 (>= 1.4.0),<br>
libcupsimage2 (>= 1.4.0), libfontconfig1 (>=<br>
2.8.0), libfreetype6 (>= 2.2.1), libgcrypt11 (>= 1.4.5),<br>
libgnutls26 (>= 2.12.6.1-0), libgssapi-krb5-2 (>=<br>
1.6.dfsg.2), libidn11 (>= 1.13), libijs-0.35 (>= 0.35),<br>
libjasper1, libjbig2dec0, libjpeg8 (>= 8c),<br>
libk5crypto3 (>= 1.6.dfsg.2), libkrb5-3 (>= 1.6.dfsg.2),<br>
liblcms2-2, libpaper1, libpng12-0 (>= 1.2.13-4),<br>
libstdc++6 (>= 4.1.1), libtiff4, zlib1g (>= 1:1.1.4),<br>
gs-cjk-resource, libgs9-common (= 9.05~dfsg-2)<br>
Description: interpreter for the PostScript language and for PDF - Library<br>
GPL Ghostscript is used for PostScript/PDF preview and printing.<br>
Usually as a back-end to a program such as ghostview,<br>
it can display PostScript and PDF documents in an X11 environment.<br>
<br>
This package provides the Ghostscript library which makes the<br>
facilities of GPL Ghostscript available to applications.<br>
Homepage: <a href="http://www.ghostscript.com/" target="_blank">http://www.ghostscript.com/</a><br>
<br>
Tags: role::shared-lib<br>
<br>
As can be seen both libraries seem to have the same function .<br>
<br>
$ sudo aptitude remove libgs8<br>
[sudo] password for shirish:<br>
<div>The following packages will be REMOVED:<br>
</div> libgs8<br>
0 packages upgraded, 0 newly installed, 1 to remove and 2 not upgraded.<br>
Need to get 0 B of archives. After unpacking 16.2 MB will be freed.<br>
D000001: deferred_remove package libgs8<br>
D000001: checking dependencies for remove `libgs8'<br>
(Reading database ... 381580 files and directories currently installed.)<br>
Removing libgs8 ...<br>
D000001: removal_bulk package libgs8<br>
D000001: removal_bulk cleaning info directory<br>
D000001: removal_bulk purging? foundpostrm=1<br>
D000001: removal done<br>
<br>
Then I tried to see if any listing is/was possible :-<br>
<br>
$ dpkg -L libgs8<br>
Package `libgs8' does not contain any files (!)<br>
<br>
$ sudo aptitude purge libgs8<br>
<div>The following packages will be REMOVED:<br>
</div> libgs8{p}<br>
0 packages upgraded, 0 newly installed, 1 to remove and 2 not upgraded.<br>
Need to get 0 B of archives. After unpacking 0 B will be used.<br>
Do you want to continue? [Y/n/?] Y<br>
D000001: deferred_remove package libgs8<br>
D000001: checking dependencies for remove `libgs8'<br>
(Reading database ... 381265 files and directories currently installed.)<br>
Removing libgs8 ...<br>
D000001: removal_bulk package libgs8<br>
D000001: removal_bulk purging? foundpostrm=1<br>
Purging configuration files for libgs8 ...<br>
D000001: removal_bulk purge done, removing list `/var/lib/dpkg/info/libgs8.list'<br>
D000001: removal_bulk purge done, removing postrm<br>
`/var/lib/dpkg/info/libgs8.postrm'<br>
D000001: removal done<br>
<br>
It seems there is/are configuration files which do get removed when<br>
you purged but it seems those are either not known by dpkg or there is<br>
some other way to find those out.<br>
<br>
As said before as well, sorry for the noise :)<br>
<div><div>--<br>
Regards,<br>
Shirish Agarwal शिरीष अग्रवाल<br>
My quotes in this email licensed under CC 3.0<br>
<a href="http://creativecommons.org/licenses/by-nc/3.0/" target="_blank">http://creativecommons.org/licenses/by-nc/3.0/</a><br>
<a href="http://flossexperiences.wordpress.com" target="_blank">http://flossexperiences.wordpress.com</a><br>
065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17<br>
</div></div></blockquote></div><br></div></div></div></div>