Re: [gentoo-dev] EAPI-2 - Let's get it started

[Brian Harring]

On Wed, Jun 11, 2008 at 01:42:34AM +0200, Bo ??rsted Andresen wrote:
> On Wednesday 11 June 2008 01:03:47 Marius Mauch wrote:
> > > Things I believe should be trivial to implement:
> > > - Custom output names in SRC_URI, also called arrows (bug #177863)
> >
> > This I'd definitely delay as it probably affects a number of things.
>
> Such as?

mirror-dist, aka the GENTOO_MIRROR infrastructure.


> > > - Limit values in $USE (bug #176467)
> >
> > Also requires little actual work, question is only if this should be
> > enabled for EAPI=0/1 as well, and how it relates to USE_EXPAND and ARCH.

eapi2 only imo, further, seems daft to limit $USE namespace while 
forcing all USE_EXPAND targets in.

Basically, IUSE should be extended to mark/state what USE_EXPAND 
namespaces it cares about- for ARCH (and friends), I'd expect they're 
pushed in regardless of IUSE.


> > > - Enable FEATURES=test by default (bug #184812)
> >
> > Only if >99% of the stable and ~arch tree and all potential "system"
> > packages build with it (IOW: no)
>
> Err.. Maybe this could have been phrased better but then I did expect you
> would look at the bug before commenting. The idea is to enable tests by
> default in EAPI 2 and beyond and let them stay off by default in EAPI 0 and
> 1. This way devs who want to use EAPI 2 will either have to fix their tests
> or RESTRICT them. Doing it this way avoids the issue of having to fix the
> whole tree all at once. Users can still choose not to go with the default.

This shouldn't be forced through by PM's, this should be forced 
through by communal dev agreement; I'd suggest getting that before 
trying to slide it into an eapi.

I'd prefer tests on, but I'm not convinced eapi level is the right 
area- realistically, that seems repo specifics (due to repo quality 
varying).  Either way, discussion is needed- I really doubt devs are 
going to be happy (let alone users if devs aren't careful) if they 
suddenly are forced to cleanup upstreams tests now, rather then as 
time permits.


> > > - default_*, allows an ebuild to redefine phases to add more
> > > functionality and then call default_$phase. Currently the default
> > > phases are lost when redefining the phases.
> >
> > Should be trivial to implement off-hand (just converting the existing
> > defaults to wrappers)
>
> So that's a candidate for EAPI 2.

base_* please, rather then default; precedent is already there via 
base.eclass.  Not a hard req however, just a suggestion.

~harring