Carsten Lohrke 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. > Agreed. There's no problem from the bash side of this, only the PM specific code.
> 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? > Well the official one is the internal Gentoo PMS repo. The Council haven't changed the policy so far this term on what is the "authoritative" PMS. (Nor of course have they accepted any of the drafts officially.) > EAPI issues may lead to a lot of confusion and eclass bloat, especially > since we still can't remove stale eclasses afaik. > Another maintenance headache, agreed. Is it possible to remove an eclass if it can be shown that there are no apps in the tree using it, say for over 2 years? That would give Gentoo equivalence with longer-term "support" from other distros, while allowing some breathing space wrt installed ebuilds. It'd be easy enough to automate a hook to move deleted eclasses to local overlay as well. > On Mittwoch, 12. Dezember 2007, Santiago M. Mola wrote: >> Nobody said that eclasses can't use new features. > > Using new features in ebuilds or eclasses relates. EAPI A using ebuild > with EAPI B using eclass (but not defining any EAPI) is your hard nut. > Shouldn't happen, but will. And bugs in eclasses unfortunately don't have > a minor impact. > >> Just that they >> cannot _set_ EAPI or assume they are working with any EAPI. > > And I say they can - under the condition that you have a defined subset of > ebuilds belonging to that eclass. And it's a major loss of flexibility in addition to the maintenance problems you highlight. A dynamic EAPI declaration in an ebuild is foolish, but testing the EAPI value in an eclass and taking alternative action, or indeed allowing dynamic setting in that context (which would require additional metadata-- in this case i think the overhead is worth it, given that eclasses are much less numerous than ebuilds, and it's actually *adding* to what we can do already) makes a lot more sense. <zlin> the kde4 eclasses in the kde4-experimental overlay set eapi=1. <zmedico> it's fine to do that, it's just too early to do that on lots of eclasses in the main tree, because EAPI=1 is too new So there's no technical reason not to to, apart from some concern about signalling die()? <Cardoe> I think putting EAPI above inherit is bad <Cardoe> because you're relying on the ebuild author to audit all the eclass code to know which EAPI version is required Ouch. Well at least EAPI anything is still experimental atm. Thank heavens for peer review :D -- [EMAIL PROTECTED] mailing list
