| 1 |
On Sun, 17 May 2009 18:58:58 +0200 |
| 2 |
Arfrever Frehtes Taifersar Arahesis <arfrever.fta@×××××.com> wrote: |
| 3 |
> > No good, for two reasons. |
| 4 |
> > |
| 5 |
> > First, this is a global scope change |
| 6 |
> |
| 7 |
> Why do you think that it is a global scope change? |
| 8 |
|
| 9 |
Package managers still need to be able to get the EAPI, even if they |
| 10 |
don't support newer EAPIs, which means you're restricted to using syntax |
| 11 |
that bash-3 can parse. Although you can sneak some bash-4 features |
| 12 |
through bash-3's parser, it gets extremely confusing. |
| 13 |
|
| 14 |
> > and we can't make global scope |
| 15 |
> > changes to EAPIs using current mechanisms. EAPIs have to carry on |
| 16 |
> > using bash 3 until the EAPI mechanism is changed. |
| 17 |
> |
| 18 |
> IMHO ebuilds are allowed to set DEPEND=">=app-shells/bash-4.0" and use |
| 19 |
> bash-4.0 features anyway, but it would be easier to just set |
| 20 |
> appropriate EAPI in ebuilds. |
| 21 |
|
| 22 |
Er, no. An ebuild's deps aren't met when the package manager generates |
| 23 |
metadata from the ebuild. |
| 24 |
|
| 25 |
> > Second, by order of the Council, EAPI 3's feature list was locked |
| 26 |
> > several weeks ago. If we ignore that for one thing, it just means |
| 27 |
> > everyone else who had features that came along too late will start |
| 28 |
> > demanding we reconsider those too... |
| 29 |
> |
| 30 |
> IMHO addition of this feature would be acceptable. |
| 31 |
|
| 32 |
You could say that about any feature, but the Council chose to just go |
| 33 |
with an absolute cutoff. |
| 34 |
|
| 35 |
-- |
| 36 |
Ciaran McCreesh |
Archives