Find stale packages in Gentoo

I often get in days of clean-up mentality, and like to go through and see how old my oldest packages are, see if I can either clean them out, or recompile them to make sure they're using the latest tool-chain enhancements.

The easiest way to do this is really just scrape the file-system MTimes, its fast, it works, and nobody cares if its not 100% accurate.

find -O3 /var/db/pkg -depth -type f -name "*.ebuild" -printf "%T@ %T+ %p/%f\n" | \
    sort -r -k 1 > /tmp/mtimes;

You now have a lovely list of files in /tmp/mtimes showing when the most recent incarnation of each currently installed package appeared to have been installed.

I tend to walk over the tail end of this and manually re-emerge them if I feel like it.

Alternatively, if you think you don't need the package any-more, you can give the reverse dependencies a quick scan.

Sometimes the portage tools are fast enough, but I find just running a grep does the trick:

grep "silgraphite" /var/db/pkg/*/*/*DEPEND* 
# /var/db/pkg/app-text/texlive-core-2010/DEPEND:... xetex? ( ...media-libs/silgraphite )
# /var/db/pkg/app-text/texlive-core-2010/RDEPEND:... xetex? ( ...media-libs/silgraphite )

Oh right, seems I do need that, so I can either tell texlive-core I don't want xetex support and then clean it out, or I can just re-merge it and then think about this problem later

For the curious people

I'm also curious somewhat as to how old my system is as a whole, and have this script I threw together.

find -O3 /var/db/pkg -depth -type f -name "*.ebuild" -printf "%T@ %T+ %p/%f\n" | \
    sort -r -k 1 > /tmp/mtimes;

for j in $(seq 2008 2010 );
do
  for i in $(seq 01 12 | sed "s/^\([0-9]\)$/0\1/" );
  do
     echo -n "$j-$i:" ;
     grep $j-$i /tmp/mtimes | wc -l ;
  done ;
done ;

And my findings tell me that most of my system is around 3-months old, and this is a good thing in my mind.

2009-10:0
2009-11:0
2009-12:1
2010-01:2
2010-02:0
2010-03:6
2010-04:27
2010-05:1
2010-06:44
2010-07:54
2010-08:88
2010-09:1094
2010-10:139
2010-11:381
2010-12:35

There's a couple things that are stuck in the past, but that's due to GCC incompatibilities/test failures, and I'll come back to these later and probably file a bug report if I can find something worth-while reporting.