Section 3.7.1 does not mention 2 requirements that apply to all current versions of portage: 1) The mtimes of the metadata/cache files must exactly match those of the corresponding ebuilds (with 1 second granularity). 2) Cache files must be exactly 22 \n terminated lines in length. If either of these two requirements is not met, the cache is useless to all current versions of portage.
(In reply to comment #0) > 1) The mtimes of the metadata/cache files must exactly match those of the > corresponding ebuilds (with 1 second granularity). The above is required for backward compatibility. However, if the user modifies an eclass in the repo which triggers a change in ebuild metadata, the ebuild mtime is insufficient information to verify that the cache is not stale. For this reason, we may want to add a new metadata key to the spec which would allow the package manager to detect staleness triggered by eclass modification. For example, we can add a 16th line containing the mtime of the most recently modified file (among the ebuild and the eclasses it inherits) expressed as the integer number of seconds elapsed since the Unix epoch.
Bleh. This is a mess. The only reason the cache things are in at all is because it's a pain in the ass to use the tree without them. I'd really rather not bog the spec down with weird things like requiring trailing blank lines and race-condition prone mtime requirements...
well, no point in mandating a half assed version when nothing actually generates/supports it ...
For the blank lines, fair enough. For the mtimes, though, I'd say no point mandating something that's defective by design that would require any compliant package manager to be broken...
yeah, the spec should cover the current state, not any additional hacks to work around its broken design ... we know we've out grown the cache format and it has many limitations ... best to freeze it now and move to something else
r148 adds the blank lines requirements. I see no way of mandating mtime issues that doesn't require broken behaviour, so I've left it unspecified.
