Note: Due to technical difficulties, the Archives are currently not up to date.
GMANE provides an alternative service for most mailing lists. c.f. bug 424647
On Dec 12, 2007 1:21 PM, Ciaran McCreesh
<ciaran.mccreesh@...> wrote:
> On Tue, 11 Dec 2007 16:59:28 -0500
> Doug Klima <cardoe@g.o> wrote:
> > discuss.
>
> * EAPI may only be set before the 'inherit' in an ebuild.
>
> * Eclasses may not set EAPI.
>
> * Eclasses may not assume a particular EAPI.
>
> * If an eclass needs to work with multiple EAPIs, EAPI-specific code
> should be split out into foo-eapiBLAH.eclass, and EAPI-agnostic code
> and a conditional inherit should remain in foo.eclass.
It seems the most reasonable option I've read until now.
Would it be possible to have eclass/eapiBLAH/foo.eclass?
> * Eclasses cannot be made not to work with any given EAPI. If such
> functionality is desirable, someone needs to file an EAPI request for
> permitting an alternative to 'die' that is legal in global scope.
So is it desirable?
If portage masks ebuilds with an unsupported EAPI, what's the point?
It'd be enough to be able to check EAPI compatibility in eclasses
quickly so repoman and others can print a nice error.
--
Santiago M. Mola
Jabber ID: cooldwind@...
--
gentoo-dev@g.o mailing list
|
|
