| 1 |
Ciaran McCreesh wrote: |
| 2 |
> On Tue, 11 Dec 2007 16:59:28 -0500 |
| 3 |
> Doug Klima <cardoe@g.o> wrote: |
| 4 |
> |
| 5 |
>> discuss. |
| 6 |
>> |
| 7 |
> |
| 8 |
> * EAPI may only be set before the 'inherit' in an ebuild. |
| 9 |
> |
| 10 |
> * Eclasses may not set EAPI. |
| 11 |
> |
| 12 |
> * Eclasses may not assume a particular EAPI. |
| 13 |
> |
| 14 |
> * If an eclass needs to work with multiple EAPIs, EAPI-specific code |
| 15 |
> should be split out into foo-eapiBLAH.eclass, and EAPI-agnostic code |
| 16 |
> and a conditional inherit should remain in foo.eclass. |
| 17 |
> |
| 18 |
> * Eclasses cannot be made not to work with any given EAPI. If such |
| 19 |
> functionality is desirable, someone needs to file an EAPI request for |
| 20 |
> permitting an alternative to 'die' that is legal in global scope. |
| 21 |
> |
| 22 |
> |
| 23 |
My point is it's fine to state this, however there needs to be |
| 24 |
enforcement of this in the associated utilities. repoman, etc. |
| 25 |
Unfortunately, eclasses are not checked at all at commit time, which |
| 26 |
would allow developers to make this potentially catastrophic change. |
| 27 |
|
| 28 |
So we're going to have "eapi 1 && inherit foo-eapi1.eclass" allowable in |
| 29 |
"foo.eclass"? When will this "eapi" keyword be available for eclasses to |
| 30 |
use? |
| 31 |
-- |
| 32 |
gentoo-dev@g.o mailing list |
Archives