Summary: | sys-apps/portage-2.2_rc33 - repoman does not distinguish between cached IUSE and present IUSE | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Jeroen Roovers (RETIRED) <jer> |
Component: | Repoman | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Jeroen Roovers (RETIRED)
![]() Apparently your cache in /var/cache/edb/dep got corrupted somehow. The way that it's supposed to work is that the timestamps of the ebuild and inherited eclasses are stored in the cache entry and those are used to validate it. Normally this works fine, but apparently something went wrong on your system. Did the IUSE change due to an eclass change that you made locally? If so, then that would explain it. If you're making local eclass changes, you need to have FEATURES=metadata-transfer enabled. This is due to a limitation in the cache format that is distributed with the rsync tree (it doesn't include eclass timestamps). In order to solve this problem, we need to extend the cache format as discussed in the "[RFC] DIGESTS metadata variable for cache validation" thread: http://archives.gentoo.org/gentoo-dev/msg_cfa80e33ee5fa6f854120ddfb9b468b3.xml (In reply to comment #1) > Apparently your cache in /var/cache/edb/dep got corrupted somehow. The way that > it's supposed to work is that the timestamps of the ebuild and inherited > eclasses are stored in the cache entry and those are used to validate it. > Normally this works fine, but apparently something went wrong on your system. > > Did the IUSE change due to an eclass change that you made locally? I use no other eclasses than those in the official tree. > If so, then > that would explain it. If you're making local eclass changes, you need to have > FEATURES=metadata-transfer enabled. I made no local eclass changes, but I didn't have FEATURES=metadata-transfer on that system either. (In reply to comment #2) > I made no local eclass changes, but I didn't have FEATURES=metadata-transfer on > that system either. Then something else must have caused the cache validation mechanism to fail. Is there a cache entry located at /var/cache/edb/dep/keeps/gentoo/portage/dev-lang/php-5.2.10 and does it contain zip-external in its IUSE value? Also, please check line 11 of /gentoo/portage/metadata/cache/dev-lang/php-5.2.10 and check if that contains zip-external. Of course, I mean '/keeps/gentoo/portage/metadata/cache/dev-lang/php-5.2.10'. This has had no activity in years, there has been so many changes to portage/repoman since then. Plus there have been no new reported occurances of this. Closing |