Note: Due to technical difficulties, the Archives are currently not up to date.
GMANE provides an alternative service for most mailing lists. c.f. bug 424647
Ciaran McCreesh wrote:
> On Tue, 11 Dec 2007 16:59:28 -0500
> Doug Klima <cardoe@g.o> 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?
--
gentoo-dev@g.o mailing list
|
|
