| 1 |
On Fri, 21 Dec 2007 11:23:08 +0800 |
| 2 |
Zhang Le <r0bertz@g.o> wrote: |
| 3 |
> > Quite the opposite. EAPI's are designed to live happily together in |
| 4 |
> > the same repository. A current example: most (or lots...) ebuilds in |
| 5 |
> > the tree don't need EAPI="1" and it's pointless to migrate all of |
| 6 |
> > them. We can switch EAPI on an as needed basis. |
| 7 |
> |
| 8 |
> But EAPI's can not always co-exist harmoniously. |
| 9 |
> What if a future EAPI come up with a totally new DEPENDENCY |
| 10 |
> setting[1], which is incompatible with existing ones. |
| 11 |
|
| 12 |
DEPENDENCIES can exist in the same tree as *DEPEND. They can't exist |
| 13 |
within the same ebuild, but that's OK because you can't mix EAPIs at |
| 14 |
that level. |
| 15 |
|
| 16 |
> I really don't see the necessity to have so many EAPI's |
| 17 |
|
| 18 |
A new EAPI is needed for new features, so new EAPIs will be needed in |
| 19 |
the future. Equally, migrating the whole tree at once to newer EAPIs is |
| 20 |
a) a lot of unnecessary work, and b) unnecessarily irritating to people |
| 21 |
using older package managers. |
| 22 |
|
| 23 |
> especially PM specific EAPI. We can't have PM specific EAPI, |
| 24 |
> otherwise we are risking forking/splitting ourself. |
| 25 |
|
| 26 |
Package manager EAPIs don't belong in the main tree, but they have uses |
| 27 |
outside of it. |
| 28 |
|
| 29 |
-- |
| 30 |
Ciaran McCreesh |
Archives