[Popcon-developers] Bug#414865: popularity-contest: A script to filter requested/recommended/suggested packages

[Christophe Lohr]

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