[gentoo-dev] Re: EAPI placement

[Steve Long]

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


-- 
gentoo-dev@g.o mailing list