I think you're missing the point. Firstly, the script is about removing distfiles, not about any form of package management per se. The objective originally was this: to remove distfiles that are superceded by those of later versions (as a result of newer versions of software). Such distfiles are completely useless in that they will never be used again unless, for some reason, you want to specifically build an older version of the package which still has an ebuild available. As it stands, it has absolutely nothing to do with what you have emerged or not (as evidenced by the complete absence of the emerge command in the entire script).
As for the idea posed in my last comment, I'll explain with an example:
1. Let's say you install cool_prog-r1 which has dependencies on aux_prog-1.0 and another_lib-1.5 to build
2. Later on your Portage tree has updated ebuilds for aux_prog-1.5 and another_lib-2.0. You emerge them. In the meantime ther older versions reamain on your system because cool_prog-r1 has *explicit* dependencies (expressed in the ebuild) for the older versions and the newer ones would break this particular package. This is what I understand SLOTS are for, otherwise Portage would simply break all kinds of software otherwise.
3. Because you emerged the newer versions of aux_prog and another_lib the newer distfiles are present, as well as the old ones. Fine.
4. You run my script to clean out older distfiles. It sees that aux_prog-1.0 is older than aux_prog-1.5 and that another_lib-1.5 is older than another_lib-2.0 so it deletes the older versions.
5. You decide you want to recompile cool_prog-r1 with some different optimisations or settings. Now Portage has to go and download the older versions of aux_prog and another_lib for *nothing*!!! It's just a waste of bandwidth.
Do you see what I'm getting at now? The idea is a bandwidth saving measurement. Because we often like to recompile our packages and because many packages are dependent on very specific versions of other packages, the idea is merely to avoid deleting distfiles which
would be used if you recompiled a build you already have on your system. IMO, the rationale behind this is sensible: if you've already compiled something, chances are that you may want to do it again in the future (not necessarily because a new version came out). Whereas the script as it stands will just delete any older version of a distfile blindly.
It seems the functionality to determine if something is safe to remove
Like I said before, my script doesn't remove packages. It removes the files containing the source code from which they were built. This comment is moot.
So the logic would be:
1) Aha, I see a distfile that is older
2) But wait a moment, the user has a package currently emerged which just happens to have a DEPEND or RDEPEND line referencing a package to which this older distfile is related. The user might want to rebuild it at a later stage and not appreciate the emerge process having to get that distfile again - so let's skip that one.
None of this functionality is in Portage. Portage doesn't have a facility to remove old distfiles, a measure which is designed to prevent tedious manual traversal of the distfiles in the interests of saving disk space, trying to guess which ones are completely redundant and judging by some of the comments I got, it is obviously something useful. I cannot see how emerge -cp is of any use whatsoever in trying to achieve this goal as it doesn't list dependencies. It only lists packages which are safe for removal because newer versions have been emerged. I'm not interested in that, because I am not trying to rewrite Portage here ....
Furthermore, why would you want to delete a distfile just because it isn't emerged on your system at the time? I have plenty of downloaded distfiles which aren't installed on my Gentoo box (I regularly use the -f parameter). That doesn't mean I won't do it tomorrow, or that I won't want to burn these distfiles on a CD to save time at another location. And it wouldn't be very nice if you used a shared distfiles directory from a server (as I do). I have Gnome distfiles in my share now which I don't intend to install on my main box yet, but maybe I want to from another. Having said that, it could be useful in some cases as an optional parameter. The problem is then you have to reliably map distfile names <-> package names (they're not necessarily the same and one package might have more than one distfile related to it - such as X). Those are the sort of problems I was hinting at. If you know how to do this cleanly and efficiently then I would like to know ...