On Dec 12, 2007 11:14 PM, Carsten Lohrke <[EMAIL PROTECTED]> wrote: > 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.
Nobody said that eclasses can't use new features. Just that they cannot _set_ EAPI or assume they are working with any EAPI. But an eclass can check which EAPI is set in the environment (that's which EAPI the ebuild set) and act accordingly, using features available on that EAPI. > > 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? EAPIs are defined in PMS [1] although I don't find an "officla" copy at gentoo.org (only the one in dev.g.o/~spb). > > EAPI issues may lead to a lot of confusion and eclass bloat, especially since > we still can't remove stale eclasses afaik. > Yep, that issue should be addresses as it is in paludis and pkgcore. [1] http://www.gentoo.org/proj/en/qa/pms.xml -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
