| 1 |
On Wednesday 11 June 2008 01:03:47 Marius Mauch wrote: |
| 2 |
> > I would like the portage devs to comment upon which of the following |
| 3 |
> > features they think could easily be implemented before portage 2.2 |
| 4 |
> > goes stable. There's still some time since it hasn't left |
| 5 |
> > package.mask yet, so I'd rather they exclude the features that will |
| 6 |
> > take too long to implement than anybody else doing that... |
| 7 |
> |
| 8 |
> Well, actually I would rather not add any new features between pre8 and |
| 9 |
> rc1 to not further delay 2.2. And generally I'm also not in favor of |
| 10 |
> adding new features during the rc phase as it's there to eliminate |
| 11 |
> remaining bugs and for refinement of existing features, not to add new |
| 12 |
> unknowns. |
| 13 |
|
| 14 |
Ok. |
| 15 |
|
| 16 |
> > Things I believe should be trivial to implement: |
| 17 |
> > - Custom output names in SRC_URI, also called arrows (bug #177863) |
| 18 |
> |
| 19 |
> This I'd definitely delay as it probably affects a number of things. |
| 20 |
|
| 21 |
Such as? |
| 22 |
|
| 23 |
> > - Limit values in $USE (bug #176467) |
| 24 |
> |
| 25 |
> Also requires little actual work, question is only if this should be |
| 26 |
> enabled for EAPI=0/1 as well, and how it relates to USE_EXPAND and ARCH. |
| 27 |
> If it should be done for existing EAPIs as well could be considered as |
| 28 |
> bugfix. |
| 29 |
> |
| 30 |
> > - doins support for symlinks (bug #179932) |
| 31 |
> |
| 32 |
> If someone implements it it can be included (do you want an EAPI bump |
| 33 |
> for that?) |
| 34 |
|
| 35 |
Listed those here because they block the EAPI tracker bug. |
| 36 |
|
| 37 |
> > - Enable FEATURES=test by default (bug #184812) |
| 38 |
> |
| 39 |
> Only if >99% of the stable and ~arch tree and all potential "system" |
| 40 |
> packages build with it (IOW: no) |
| 41 |
|
| 42 |
Err.. Maybe this could have been phrased better but then I did expect you |
| 43 |
would look at the bug before commenting. The idea is to enable tests by |
| 44 |
default in EAPI 2 and beyond and let them stay off by default in EAPI 0 and |
| 45 |
1. This way devs who want to use EAPI 2 will either have to fix their tests |
| 46 |
or RESTRICT them. Doing it this way avoids the issue of having to fix the |
| 47 |
whole tree all at once. Users can still choose not to go with the default. |
| 48 |
|
| 49 |
> > - GLEP 42 - news items |
| 50 |
> |
| 51 |
> Already implemented. |
| 52 |
|
| 53 |
And not really an EAPI issue. Hence I shouldn't have mentioned it here. ;) |
| 54 |
|
| 55 |
> > - default_*, allows an ebuild to redefine phases to add more |
| 56 |
> > functionality and then call default_$phase. Currently the default |
| 57 |
> > phases are lost when redefining the phases. |
| 58 |
> |
| 59 |
> Should be trivial to implement off-hand (just converting the existing |
| 60 |
> defaults to wrappers) |
| 61 |
|
| 62 |
So that's a candidate for EAPI 2. |
| 63 |
|
| 64 |
> > - default for src_install (bug #33544) |
| 65 |
> |
| 66 |
> Should also not be terribly difficult, though I'd rather wait until |
| 67 |
> after 2.2 final. |
| 68 |
|
| 69 |
-- |
| 70 |
Bo Andresen |
| 71 |
Gentoo KDE Dev |
Archives