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'. /haubi/ -- Michael Haubenwallner Gentoo on a different level
