Ciaran McCreesh wrote: > On Tue, 11 Dec 2007 16:59:28 -0500 > Doug Klima <[EMAIL PROTECTED]> wrote: > >> discuss. >> > > * EAPI may only be set before the 'inherit' in an ebuild. > > * Eclasses may not set EAPI. > > * Eclasses may not assume a particular EAPI. > > * If an eclass needs to work with multiple EAPIs, EAPI-specific code > should be split out into foo-eapiBLAH.eclass, and EAPI-agnostic code > and a conditional inherit should remain in foo.eclass. > > * Eclasses cannot be made not to work with any given EAPI. If such > functionality is desirable, someone needs to file an EAPI request for > permitting an alternative to 'die' that is legal in global scope. > > My point is it's fine to state this, however there needs to be enforcement of this in the associated utilities. repoman, etc. Unfortunately, eclasses are not checked at all at commit time, which would allow developers to make this potentially catastrophic change.
So we're going to have "eapi 1 && inherit foo-eapi1.eclass" allowable in "foo.eclass"? When will this "eapi" keyword be available for eclasses to use? -- [EMAIL PROTECTED] mailing list
