| 1 |
On Dec 12, 2007 11:14 PM, Carsten Lohrke <carlo@g.o> wrote: |
| 2 |
> On Mittwoch, 12. Dezember 2007, Ciaran McCreesh wrote: |
| 3 |
> > * Eclasses may not set EAPI. |
| 4 |
> > |
| 5 |
> > * Eclasses may not assume a particular EAPI. |
| 6 |
> |
| 7 |
> I disagree here. It would be annoying and possibly even hindering in future |
| 8 |
> not being able to use higher EAPI features in eclasses. Point is the eclass |
| 9 |
> has to check, if the author of an ebuild sets another EAPI and throw an |
| 10 |
> error, in this case. |
| 11 |
|
| 12 |
Nobody said that eclasses can't use new features. Just that they |
| 13 |
cannot _set_ EAPI or assume they are working with any EAPI. But an |
| 14 |
eclass can check which EAPI is set in the environment (that's which |
| 15 |
EAPI the ebuild set) and act accordingly, using features available on |
| 16 |
that EAPI. |
| 17 |
|
| 18 |
> |
| 19 |
> The most basic issue, which we didn't even discuss yet, afaik, is how to make |
| 20 |
> every developer aware which feature belongs to which EAPI. I freely admit, I |
| 21 |
> do not know that. Is there a list somewhere? |
| 22 |
|
| 23 |
EAPIs are defined in PMS [1] although I don't find an "officla" copy |
| 24 |
at gentoo.org (only the one in dev.g.o/~spb). |
| 25 |
|
| 26 |
> |
| 27 |
> EAPI issues may lead to a lot of confusion and eclass bloat, especially since |
| 28 |
> we still can't remove stale eclasses afaik. |
| 29 |
> |
| 30 |
|
| 31 |
Yep, that issue should be addresses as it is in paludis and pkgcore. |
| 32 |
|
| 33 |
[1] http://www.gentoo.org/proj/en/qa/pms.xml |
| 34 |
|
| 35 |
-- |
| 36 |
Santiago M. Mola |
| 37 |
Jabber ID: cooldwind@×××××.com |
| 38 |
-- |
| 39 |
gentoo-dev@g.o mailing list |
Archives