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:35There'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.