I'm using cvs $PORTDIR, thus I run emerge --regen after cvs up and then update-eix. My cache setting is thus the default of portage >2.1 ("backport"). Emerge --regen doesn't remove cache entries of ebuilds that were removed, and that's fine according to portage people. Portage doesn't take this metadata into any calculations if the ebuild also doesn't exist. But eix processes only the metadata cache, and then it shows versions of packages that no longer exist. This won't happen to users with $PORTDIR/metadata cache because there the stale entries are removed on the generating server. But emerge --regen doesn't have an option to remove stale entries, so I think eix should have some option to check if the ebuilds really exists when generating the index.
I consider it a bug of portage that its cache keeps orphant data (even if it does not harm the actual execution of portage). My suggestion is to run rm -rf /var/cache/edb/dep/* before doing emerge --regen: This is essentially what eix-sync does, too, and it is faster than any subsequent workaround within update-eix might ever be (simply testing the existence of each ebuild in the cache would take an enormous amount of time). You might e.g. use a script which fetches the new cvs, does rm -rf /var/cache/edb/dep/*, calls emerge --regen and update-eix; depending on your needs, even eix-sync might be your script of choice after an appropriate configuration. Alternatively, you can use PORTDIR_CACHE_METHOD=ebuild or something similar (but of course, this is also horribly slow).
I told him the same before, cantfix :(
(In reply to comment #1) > I consider it a bug of portage that its cache keeps orphant data (even if it > does not harm the actual execution of portage). Yeah, Zac accepted that as bug in the end. > My suggestion is to run > rm -rf /var/cache/edb/dep/* > before doing emerge --regen: This is essentially what eix-sync does, too, and > it is faster than any subsequent workaround within update-eix might ever be emerge --regen from a empty cache takes VERY VERY long, if the cache is almost-uptodate, it will just process the new/changed ebuilds > (simply testing the existence of each ebuild in the cache would take an > enormous amount of time). Not that enormous compared to --regen from empty cache. > You might e.g. use a script which fetches the new > cvs, does rm -rf /var/cache/edb/dep/*, calls emerge --regen and update-eix; > depending on your needs, even eix-sync might be your script of choice after an > appropriate configuration. I created a simple bash script that will walk through the cache, check if the ebuild exists and remove the cached file if not. Takes about 2 minutes (that's nothing compared to --regen from empty cache), so I will just use this until --regen is fixed. Sorry for the needless bug.
