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

shirish शिरीष shirishag75 at gmail.com
Mon Feb 27 12:56:12 UTC 2012

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

Sorry for the noise :)
          Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
065C 6D79 A68C E7EA 52B3  8D70 950D 53FB 729A 8B17

More information about the Aptitude-devel mailing list