On Wednesday 11 June 2008 01:03:47 Marius Mauch wrote:
> > I would like the portage devs to comment upon which of the following
> > features they think could easily be implemented before portage 2.2
> > goes stable. There's still some time since it hasn't left
> > package.mask yet, so I'd rather they exclude the features that will
> > take too long to implement than anybody else doing that...
> Well, actually I would rather not add any new features between pre8 and
> rc1 to not further delay 2.2. And generally I'm also not in favor of
> adding new features during the rc phase as it's there to eliminate
> remaining bugs and for refinement of existing features, not to add new
> > 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.
> > - 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.
> If it should be done for existing EAPIs as well could be considered as
> > - doins support for symlinks (bug #179932)
> If someone implements it it can be included (do you want an EAPI bump
> for that?)
Listed those here because they block the EAPI tracker bug.
> > - 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.
> > - GLEP 42 - news items
> Already implemented.
And not really an EAPI issue. Hence I shouldn't have mentioned it here.
> > - 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.
> > - default for src_install (bug #33544)
> Should also not be terribly difficult, though I'd rather wait until
> after 2.2 final.
Gentoo KDE Dev