On Dec 12, 2007 1:21 PM, Ciaran McCreesh <[EMAIL PROTECTED]> 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.
It seems the most reasonable option I've read until now. Would it be possible to have eclass/eapiBLAH/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. So is it desirable? If portage masks ebuilds with an unsupported EAPI, what's the point? It'd be enough to be able to check EAPI compatibility in eclasses quickly so repoman and others can print a nice error. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
