On Mittwoch, 12. Dezember 2007, Ciaran McCreesh wrote: > * Eclasses may not set EAPI. > > * Eclasses may not assume a particular EAPI.
I disagree here. It would be annoying and possibly even hindering in future not being able to use higher EAPI features in eclasses. Point is the eclass has to check, if the author of an ebuild sets another EAPI and throw an error, in this case. The most basic issue, which we didn't even discuss yet, afaik, is how to make every developer aware which feature belongs to which EAPI. I freely admit, I do not know that. Is there a list somewhere? EAPI issues may lead to a lot of confusion and eclass bloat, especially since we still can't remove stale eclasses afaik. Carsten
signature.asc
Description: This is a digitally signed message part.
