Summary: | PROPERTIES="interactive" is not detected for overlay ebuilds with existing cache entries generated by older portage | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Fab <netbox253> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | esigra, wolf31o2 |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 151113 |
Description
Fab
2008-11-27 18:40:53 UTC
Assuming that PROPERTIES=interactive is set in the ebuild, the problem is may be due to stale cache in /var/cache/edb/dep/. Have you use /etc/portage/modules to override the default portdbapi.auxdbmodule setting? Does it help if you use `touch doom3-data-1.1.1282-r1.ebuild` to bump the timestamp on the ebuild? (In reply to comment #1) > Have you use /etc/portage/modules to override the default portdbapi.auxdbmodule setting? No. > Does it help if you use `touch doom3-data-1.1.1282-r1.ebuild` to bump the timestamp on the ebuild? Yes, it solve the problem, thanks. I guess the stale cache entry was generated by an older version of portage. There's currently no way for portage to know that, but we could start putting a version stamp inside the cache entries for this purpose. Then we'd have to bump the version any time that a new key such as PROPERTIES is added. (In reply to comment #3) > I guess the stale cache entry was generated by an older version of portage. Yes, last time I modified and emerged this ebuild, it was with portage 2.1.4.5. > but we could start putting a version stamp inside the cache entries > for this purpose. Then we'd have to bump the version any time that a new key > such as PROPERTIES is added. Why not just delete the overlays's cache when necessary on a portage update ? (delete everything in /var/cache/edb/dep, except /var/cache/edb/dep/${PORTDIR}, to make sure that cache entries from disabled overlays are clean) (In reply to comment #4) > Why not just delete the overlays's cache when necessary on a portage update ? > (delete everything in /var/cache/edb/dep, except /var/cache/edb/dep/${PORTDIR}, > to make sure that cache entries from disabled overlays are clean) That's sort of invasive, so things like that are normally done at the user's discretion, such as by displaying an ewarn message instructing them what to do. An alternative to a rea; version stamp would be to use a marker to indicate that a given key such as PROPERTIES is supported be the version of portage that generated the cache entry. For example, instead of omitting PROPERTIES from the cache entry when PROPERTIES happens to be empty, PROPERTIES=( ) could be used to indicate that PROPERTIES is supported but happens to be empty. This should be practically irrelevant now. |