Carsten Hey a écrit :
> No, #414865 is assigned to popularity-contest and the proposed "fix" is
> a fork of orphaner.
>
>> I think you are mixing two unrelated bugs.
>>
Well, the situation is a little bit confusing... It is my fault.
My first need is rather classical: my hard disk is full now. However, I'm
convinced that I have a lot of installed packets on it that I never have
used, that I never use, that I do not even know they exist and are present
on my system...
That's why I'm looking for something that can help my to clean my system.
popularity-contest gives an first answer: it compute a "date of last use"
for each packet. This date is based on the most recent atime of each file
(except config files) provided by a packet (it also pay attention to
files in
memory).
This date can be disturbed when the packet was not used since last
time it was updated.
Moreover, popularity-contest adds the tag <OLD> to packets not used for tree
months. This value of tree months is hardcoded into the perl script.
Despite the two above-mentionned points, I think the tag <OLD> is
significant enough for my need.
As an addition, popcon-largest-unused sorts output of popularity-contest by
installed size of <OLD> packets. This point is interesting since it helps me
to take a decision for heavier packets first.
However, it has been pointed out (bug 414865) that within the list of
suggested packets to remove, some of them are requested by others as a
dependency.
So, my firts contribution was in this direction: a simple shell script named
"popcon-nodependency" that lists packets that are requested by others (with
dpkg-query -W -f='${Depends} ${Recommends} ${Suggests} ') and checks if
suggested packets to remove are on this list or not.
See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=414865#20
My second contribution was a second shell script to do this recursively
interacting with the administrator. For that, I deeply reuse the code of
orphaner (the two problems are very closed).
This is the reason why we are now talking both about popularity-contest and
orphaner.
But perhaps deborphan and orphaner can do most of the work themselves.
deborphan is able to manages the dependency better than a grep in a list,
and orphaner does interaction with the administrator.
So, deborphan and orphaner has to be "modularized" in some way for that.
Regards
Christophe
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
