Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

[Fabian Groffen]

On 11-11-2007 19:27:50 +0000, Ciaran McCreesh wrote:
> On Sun, 11 Nov 2007 21:21:30 +0200
> Petteri Räty <betelgeuse@g.o> wrote:
> > > Neither EAPI 0 nor EAPI 1 provide any mechanism for an ebuild to
> > > 'die' at global scope. There's simply no way for eclasses to
> > > complain that they're being misused.
> >
> > Well nothing formal but the ebuild developer should pick up ewarn/echo
> > /whatever messages coming from global scope. That's what we have in
> > debug.eclass atm.
>
> Past experience has shown that those messages will end up being seen by
> end users and not being picked up by developers. People changing
> eclasses generally don't force a metadata generation for every package
> that uses the eclass.
>
> I suspect that for existing eclasses, the safest way to proceed is to
> make a new eclass and move common code into a third eclass. So you'd
> have foo.eclass doing EAPI 0 specific stuff and inheriting foo-common,
> and foo-eapi1.eclass doing EAPI 1 specific stuff and inheriting
> foo-common.

This is indeed a very valid point that at least I have ignored for now.

In order (for me) not to mix up all kinds of issues here, this is my
percieved state with regard to EAPI.

EAPI=0 is the assumed to be used EAPI when no EAPI is specified in an
ebuild.  EAPI=1 as supported by Portage is like an extension of EAPI=0
where EAPI=0 is like a subset of EAPI=1.  For this reason current (soon
to be stable?) Portage, and at least the trunk version have EAPI=1
support, but can deal with EAPI=0 ebuilds fine.

In this setting, one could say that eclasses should remain EAPI=0, such
that all ebuilds will be able to work with them.

However, if an EAPI will require some change that makes it backwards
incompatible then this won't work any more.  What you get is that e.g.
for an eclass to work properly it needs to know about variable X, which
of course on previous EAPIs does not exist, and hence can result in
undesired behaviour.

While Ciaran's suggestion would allow some things to work there, it
still does not deal with the issue that eclasses should actually be
marked with an EAPI level too.  (Ideally they also would be part of the
digests of an ebuild, but that aside.)  A slight alternative to Ciaran's
idea here would be to make EAPI1, EAPI2 etc. subdirs in the eclass
directory where sort of eclass overloading can be done.  This would only
solve eclasses not to have an EAPI= in it, so they don't overwrite the
ebuild's value.


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@g.o mailing list