| 1 |
On Sun, 24 Oct 2010 23:47:56 +0200 |
| 2 |
Arfrever Frehtes Taifersar Arahesis <Arfrever@g.o> wrote: |
| 3 |
> > > Usage of new EAPIs in the tree is not allowed before council |
| 4 |
> > > approval. |
| 5 |
> > |
| 6 |
> > python.eclass doesn't use any EAPIs, it only provides support for |
| 7 |
> > ebuilds, which use given EAPIs (without EAPI="4"). |
| 8 |
> |
| 9 |
> I forgot to say that this patch doesn't introduce usage of any |
| 10 |
> feature absent in EAPI="3" and present in current draft of EAPI="4", |
| 11 |
> but changes API of python.eclass in EAPI="4". |
| 12 |
|
| 13 |
For all we know, EAPI 4 may be completely changed next week and then |
| 14 |
allowed in the tree the week after. Then people looking at your eclass |
| 15 |
will incorrectly assume that it supports the approved EAPI 4. |
| 16 |
|
| 17 |
EAPI 4's current state used to be "closed, and approved subject to |
| 18 |
Portage implementation", but due to the huge delays in that there have |
| 19 |
been a number of things since then that the Council has voted on that |
| 20 |
no-one has provided PMS patches or even approximate wording for. Unless |
| 21 |
you've been keeping very close track of that, you don't even know what |
| 22 |
EAPI 4 is likely to contain, let alone what it eventually will |
| 23 |
contain... |
| 24 |
|
| 25 |
-- |
| 26 |
Ciaran McCreesh |
Archives