Bug#661188: [Aptitude-devel] Bug#661188: aptitude purge package recursively REMOVES BUT DOES NOT PURGE the unneeded dependencies of package
retitle 661188 aptitude: recursive remove (like pacman -Rs) severity 661188 wishlist thanks 2012/2/29 Georgiy Treyvus georgiytrey...@gmail.com: @Daniel: The way Arch does it is actually pretty elegant. Autoremoving is cool don't get me wrong but there are times that you just want a recursive remove/purge of a given package. Sometimes people want do a recursive removal of A but a regular one for B because they'll be installing another package with most if not all of the same dependencies. Ok, this is a reasonable scenario. I see this is an advantage over marking dependencies as manually installed, however, given that the user knows they wish to install C, this is more-or-less covered by: # aptitude remove B C+ which means to remove B and install C at the same time. Dependencies used by C which would be orphaned by B will be kept in place. The same can also be done interactively. Alternatively (and not specifically how you desire this to work), disable Aptitude::Delete-Unused before removing B, perform any other activities, then enable it after C is installed. No orphaned dependencies will be removed during that period, but such are cleaned up at the end. In any case, I will leave this open for anyone who wishes to implement the pacman-style recursive remove. Autoremove is a great feature but it should be at the users discretion as in Arch. Aptitude::Delete-Unused already puts this at the user's discretion ;-) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661188: [Aptitude-devel] Bug#661188: aptitude purge package recursively REMOVES BUT DOES NOT PURGE the unneeded dependencies of package
I too have been bitten by this in the past and do think what Daniel has given as an answer is okish (although there should be some sort of better way.) For my exchange see [0] . One of the things which I didn't know to figure out how to produce a listing of such packages using aptitude [1] which was shared by Daniel as well. As I have removed all the packages which were removed haven't been able to test out if dpkg -L works on such packages as well or not. George if you have some packages whose configuration files are still it would be nice if you could produce a listing of what you get. If you do get the location of those files then a user could attempt at least to know what they contain and perhaps judge (or not) whether it could be useful now or latter. Another point to be kept at back of mind as well is over a period of time a package could merge other packages in it or be split in one or more packages, in the former the config files remaining the same (while binary is removed) while at the latter more config files would perhaps be added. I have a very vague sense of how aptitude does things so I might be right (or not). I do hope however that my $0.02 does prove to be useful to you otherwise simply disregard it. 0 - http://lists.alioth.debian.org/pipermail/aptitude-devel/2012-February/001945.html 1 - aptitude search ?config-files 2 - dpkg -L = -L|--listfiles package ... List files `owned' by package(s). A healthy package displays something like this , a random e.g. :- $ dpkg -L fonts-gubbi /. /etc /etc/fonts /etc/fonts/conf.avail /etc/fonts/conf.avail/65-0-fonts-gubbi.conf /etc/fonts/conf.d /usr /usr/share /usr/share/doc /usr/share/doc/fonts-gubbi /usr/share/doc/fonts-gubbi/changelog.gz /usr/share/doc/fonts-gubbi/changelog.Debian.gz /usr/share/doc/fonts-gubbi/copyright /usr/share/fonts /usr/share/fonts/truetype /usr/share/fonts/truetype/Gubbi /usr/share/fonts/truetype/Gubbi/Gubbi.ttf /etc/fonts/conf.d/65-0-fonts-gubbi.conf Sorry for the noise :) -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com 065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661188: [Aptitude-devel] Bug#661188: aptitude purge package recursively REMOVES BUT DOES NOT PURGE the unneeded dependencies of package
some additions :- 2012/2/27 shirish शिरीष shirisha...@gmail.com: I too have been bitten by this in the past and do think what Daniel has given as an answer is okish (although there should be some sort of better way.) For my exchange see [0] . One of the things which I didn't know to figure out how to produce a listing of such packages using aptitude [1] which was shared by Daniel as well. As I have purged all the packages which were removed haven't been able to test out if dpkg -L (2) works on such packages as well or not. George if you have some packages whose configuration files are still it would be nice if you could produce a listing of what you get. If you do get the location of those files then a user could attempt at least to know what they contain and perhaps judge (or not) whether it could be useful now or latter. Another point to be kept at back of mind as well is over a period of time a package could merge other packages in it or be split in one or more packages, in the former the config files remaining the same (while binary is removed) while at the latter more config files would perhaps be added. I have a very vague sense of how aptitude does things so I might be right (or not). I do hope however that my $0.02 does prove to be useful to you otherwise simply disregard it. 0 - http://lists.alioth.debian.org/pipermail/aptitude-devel/2012-February/001945.html 1 - aptitude search ?config-files 2 - dpkg -L = -L|--listfiles package ... List files `owned' by package(s). A healthy package displays something like this , a random e.g. :- $ dpkg -L fonts-gubbi /. /etc /etc/fonts /etc/fonts/conf.avail /etc/fonts/conf.avail/65-0-fonts-gubbi.conf /etc/fonts/conf.d /usr /usr/share /usr/share/doc /usr/share/doc/fonts-gubbi /usr/share/doc/fonts-gubbi/changelog.gz /usr/share/doc/fonts-gubbi/changelog.Debian.gz /usr/share/doc/fonts-gubbi/copyright /usr/share/fonts /usr/share/fonts/truetype /usr/share/fonts/truetype/Gubbi /usr/share/fonts/truetype/Gubbi/Gubbi.ttf /etc/fonts/conf.d/65-0-fonts-gubbi.conf I did try it just now with a library which I know is no longer needed (although aptitude hasn't removed/purged it). This is on a Debian sid machine. $ aptitude search libgs? p libgs-dev - interpreter for the PostScript language and for PDF - Develop v libgs-esp-dev - i libgs8 - The Ghostscript PostScript/PDF interpreter Library i A libgs9 - interpreter for the PostScript language and for PDF - Library i A libgs9-common - interpreter for the PostScript language and for PDF - common Just extracted partial listing. It seems aptitude doesn't respect the wildcard '?' as it produces a whole listing but that I guess is another issue. See libgs8 :- $ aptitude show libgs8 Package: libgs8 State: installed Version: 8.71~dfsg2-9 Priority: optional Section: libs Maintainer: Debian Printing Team debian-print...@lists.debian.org Uncompressed Size: 16.2 M Depends: libc6 (= 2.7), libcomerr2 (= 1.01), libcups2 (= 1.4.0), libcupsimage2 (= 1.4.0), libfontconfig1 (= 2.8.0), libgcrypt11 (= 1.4.2), libgnutls26 (= 2.7.14-0), libgssapi-krb5-2 (= 1.6.dfsg.2), libjasper1 (= 1.900.1), libjbig2dec0, libjpeg62 (= 6b1), libk5crypto3 (= 1.6.dfsg.2), libkrb5-3 (= 1.6.dfsg.2), libpaper1, libpng12-0 (= 1.2.13-4), libstdc++6 (= 4.1.1), libtiff4, zlib1g (= 1:1.1.4) Breaks: ghostscript ( 8.71~dfsg2-7) Replaces: ghostscript ( 8.71~dfsg2-7) Description: The Ghostscript PostScript/PDF interpreter Library Ghostscript is used for PostScript/PDF preview and printing. Usually as a back-end to a program such as ghostview, it can display PostScript and PDF documents in an X11 environment. This package provides the Ghostscript library which makes the facilities of Ghostscript available to applications. Homepage: http://www.ghostscript.com/ Tags: implemented-in::c, role::shared-lib, use::printing, use::viewing, works-with-format::pdf, works-with-format::postscript Looking at libgs9 now :- $ aptitude show libgs9 Package: libgs9 State: installed Automatically installed: yes Version: 9.05~dfsg-2 Priority: optional Section: libs Maintainer: Debian Printing Team debian-print...@lists.debian.org Uncompressed Size: 10.4 M Depends: libc6 (= 2.7), libcomerr2 (= 1.01), libcups2 (= 1.4.0), libcupsimage2 (= 1.4.0), libfontconfig1 (= 2.8.0), libfreetype6 (= 2.2.1), libgcrypt11 (= 1.4.5), libgnutls26 (= 2.12.6.1-0), libgssapi-krb5-2 (= 1.6.dfsg.2), libidn11 (= 1.13), libijs-0.35 (= 0.35), libjasper1, libjbig2dec0, libjpeg8 (= 8c), libk5crypto3 (= 1.6.dfsg.2), libkrb5-3 (= 1.6.dfsg.2), liblcms2-2, libpaper1, libpng12-0 (= 1.2.13-4), libstdc++6 (= 4.1.1), libtiff4, zlib1g (= 1:1.1.4), gs-cjk-resource, libgs9-common (=
Bug#661188: [Aptitude-devel] Bug#661188: aptitude purge package recursively REMOVES BUT DOES NOT PURGE the unneeded dependencies of package
2012/2/28 Georgiy Treyvus georgiytrey...@gmail.com: 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. Could you point out where the documentation is unclear, or how precisely it could be made more clear? The descriptions for purge and remove do not in any way state that dependencies will also be acted on. The behaviour of removing unused dependencies is part of a separate cleanup action which aptitude performs. This is controlled and documented by the configuration item Aptitude::Delete-Unused. IMO, the understanding that aptitude purge pkg means purge pkg and also purge all of it's unused dependencies is not contained in the docs. But that's me :-) With Delete-Unused (the default), aptitude x means do x; then clean up any unused packages. 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 I believe this type of thing is the job of tasks and tasksel. However, I have made a note of it anyway. Speaking of the automated install it should not be in the advanced section of the installation disk and should be more visible to n00bs... You will have to direct such suggestions to the debian-installer team. 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 Yes. This is the intended and documented behaviour--see above. If you set Aptitude::Delete-Unused to 'false' then: aptitude remove package == apt-get remove package 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: … So the user in this situation desires to keep B and C installed? In the APT world such a desire is indicated to the package manager by marking those packages as manually installed. It seems the crux of what you are after is a middle ground between remove and autoremove? You mention that pacman supports this. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661188: [Aptitude-devel] Bug#661188: aptitude purge package recursively REMOVES BUT DOES NOT PURGE the unneeded dependencies of package
in-line :- 2012/2/28 Georgiy Treyvus georgiytrey...@gmail.com: @Shirish: 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? to put it very simply, I do not know of a way to figure out where the .conf file after a package is removed. This is what I was trying to show/figure out. Till as a user its not known where the .conf file is (is it in .config/ or /etc or somewhere else altogether) its not easy for the user (for e.g. me) to figure out whether that .conf file does have value or I should simply get rid of it. The dpkg -L was for showing that no info. is given for that (no info. after removing libgs8) although from what has been said/shared there are conf file present somewhere. $ dpkg -L libgs8 Package `libgs8' does not contain any files (!) The 'aptitude purge $packagename' example I used was to show that specific line which said it is removing the conffile D01: removal_bulk purging? foundpostrm=1 Purging configuration files for libgs8 ... D01: removal_bulk purge done, removing list `/var/lib/dpkg/info/libgs8.list' See the second line ' Purging configuration files for libgs8' . My issue is where these configuration files are, is not known to the user and unless he knows at least where the configuration files are how is s/he going to take a call. I do know that some packages have their configuration files in /etc/ such as say dpkg /etc/dpkg$ ls dpkg.cfg dpkg.cfg.d dpkg.cfg.original origins shlibs.default shlibs.override This is possible to know by the listing of 'dpkg -L dpkg' as it does show the location of the configuration file but libgs8 does not. Similarly I have seen quite a few other packages which do not seem to have this information. At the very end I just have one question :- a. Is there a way to know/figure out where the configuration files of a given package are ? Maybe its different for binary packages and/or libraries , if so does somebody know how one can reliably find out ? Unless the above info. is not there, its really hard (at least for me) to even begin to ascertain whether doing a purge or not is good in any case at all. @ Georgiy Treyvus I do hope I was clear this time around. If not, please lemme know and I would try again. -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com 065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661188: [Aptitude-devel] Bug#661188: aptitude purge package recursively REMOVES BUT DOES NOT PURGE the unneeded dependencies of package
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. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
