Michael Haubenwallner wrote:
Hi, Reminder (for myself): As long as we want/have to support PMs lacking EAPI detection in '*.ebuild' to mask ebuilds with unknown EAPI, each approach to add EAPI to an '*.ebuild' must be hackish. So we can try to find the least ugly hack, or we need to change the extension. So just another idea, based on the "eapi() function" one: As inherit() is the only(?) global function provided by old PMs, the first non-commentary/non-blank line in '*.ebuild' could read: inherit eapi Compliant PMs identify 'eapi' as a special eclass name (with or without sourcing the ebuild), to know that "this ebuild specifies an EAPI". For non-compliant PMs, we need to provide an 'eapi.eclass', which just spits some 'your PM lacks EAPI support' message and causes the PM to mask this ebuild 'by corruption' or the like. Or - what are old PM's messages when an eclass is missing? Eventually, this line also could finally specify the EAPI and read: inherit eapi 4 Because non-compliant PM's already quit because of (missing or dying) eapi.eclass, there is no need to have a '4.eclass'.
How would the 4.eclass determine whether the package manager actually supports the eapi?
inherit is a function remember so any "special" parsing will not change the fact the the inherit function will be called. Will then need to determine whether there is actually a PM that doesn't support the eclasses EAPI and then die. What are the implications of calling inherit multiple times within an ebuild?
Im sorry, but this just sounds like a HACK, and a hacky hack at that.
/haubi/
