| 1 |
On Dec 12, 2007 1:21 PM, Ciaran McCreesh |
| 2 |
<ciaran.mccreesh@×××××××××××××.uk> wrote: |
| 3 |
> On Tue, 11 Dec 2007 16:59:28 -0500 |
| 4 |
> Doug Klima <cardoe@g.o> wrote: |
| 5 |
> > discuss. |
| 6 |
> |
| 7 |
> * EAPI may only be set before the 'inherit' in an ebuild. |
| 8 |
> |
| 9 |
> * Eclasses may not set EAPI. |
| 10 |
> |
| 11 |
> * Eclasses may not assume a particular EAPI. |
| 12 |
> |
| 13 |
> * If an eclass needs to work with multiple EAPIs, EAPI-specific code |
| 14 |
> should be split out into foo-eapiBLAH.eclass, and EAPI-agnostic code |
| 15 |
> and a conditional inherit should remain in foo.eclass. |
| 16 |
|
| 17 |
It seems the most reasonable option I've read until now. |
| 18 |
|
| 19 |
Would it be possible to have eclass/eapiBLAH/foo.eclass? |
| 20 |
|
| 21 |
> * Eclasses cannot be made not to work with any given EAPI. If such |
| 22 |
> functionality is desirable, someone needs to file an EAPI request for |
| 23 |
> permitting an alternative to 'die' that is legal in global scope. |
| 24 |
|
| 25 |
So is it desirable? |
| 26 |
|
| 27 |
If portage masks ebuilds with an unsupported EAPI, what's the point? |
| 28 |
It'd be enough to be able to check EAPI compatibility in eclasses |
| 29 |
quickly so repoman and others can print a nice error. |
| 30 |
|
| 31 |
-- |
| 32 |
Santiago M. Mola |
| 33 |
Jabber ID: cooldwind@×××××.com |
| 34 |
-- |
| 35 |
gentoo-dev@g.o mailing list |
Archives