| 1 |
On Fri, 21 Dec 2007 12:15:10 +0800 |
| 2 |
Zhang Le <r0bertz@g.o> wrote: |
| 3 |
> I think we should first decide on how EAPI works. |
| 4 |
|
| 5 |
That was decided a long time ago. |
| 6 |
|
| 7 |
> Just because we need a new feature, then we produce a new EAPI? |
| 8 |
> I think that is not feasible, and will confuse developers. |
| 9 |
|
| 10 |
Uh... Yes. It's entirely feasible, it's how things work and it's an |
| 11 |
entirely sensible model. |
| 12 |
|
| 13 |
The *problem* is not EAPI itself. The problem is how EAPI is currently |
| 14 |
specified by ebuilds. That's all the GLEP changes, and all it really |
| 15 |
needs to change. |
| 16 |
|
| 17 |
> >> especially PM specific EAPI. We can't have PM specific EAPI, |
| 18 |
> >> otherwise we are risking forking/splitting ourself. |
| 19 |
> > |
| 20 |
> > Package manager EAPIs don't belong in the main tree, but they have |
| 21 |
> > uses outside of it. |
| 22 |
> |
| 23 |
> Then would you please introduce how paludis-1 EAPI differs from |
| 24 |
> official EAPI's? |
| 25 |
|
| 26 |
It has a bunch of arbitrary, randomly changing features that I need |
| 27 |
when doing test cases for functionality that isn't covered by any |
| 28 |
official EAPI. For example, a long before EAPI 1 came along, Paludis |
| 29 |
had slot dep support. In order to test slot deps, we needed an EAPI |
| 30 |
that permitted them -- hence paludis-1. |
| 31 |
|
| 32 |
-- |
| 33 |
Ciaran McCreesh |
Archives