On Mon, 17 Dec 2007 18:46:12 -0700 Joe Peterson <[EMAIL PROTECTED]> wrote:
> What about storing a copy of the EAPI in the Manifest file - when > "ebuild ... digest" is done? That way, it will always match the one > authoritative "post-source" EAPI setting, since changing the ebuild > will require a new digest run anyway. We have control over the > format of Manifest, so parsing it can be fast. No chance. > If Manifest is not a good candidate, put them in an optional "EAPI" > file (which can then also be included in the Manifest). If the > external EAPI info for an ebuild is not found, then drop back to > assuming it does not have a defined pre-source EAPI. While I also dislike using the filename extension this would be an even greater mess (we're trying to reduce the number of files in the repository, so adding another 20k tiny files would require an extremely good reason). My personal opinion is that EAPI is the wrong angle to solve the issue with versioning, that's something that should be dealt with at the repository level (as it will eventually impact comparison rules between "old-style" versions as well, and those by definition can't be changed on a per-package base). That leaves the argument about global-scope functions, for which there are workarounds (not solutions), and without actual use cases it's a bit hard to evaluate cost and benefits. Marius -- [EMAIL PROTECTED] mailing list
