| 1 |
On Mittwoch, 12. Dezember 2007, Ciaran McCreesh wrote: |
| 2 |
> * Eclasses may not set EAPI. |
| 3 |
> |
| 4 |
> * Eclasses may not assume a particular EAPI. |
| 5 |
|
| 6 |
I disagree here. It would be annoying and possibly even hindering in future |
| 7 |
not being able to use higher EAPI features in eclasses. Point is the eclass |
| 8 |
has to check, if the author of an ebuild sets another EAPI and throw an |
| 9 |
error, in this case. |
| 10 |
|
| 11 |
|
| 12 |
The most basic issue, which we didn't even discuss yet, afaik, is how to make |
| 13 |
every developer aware which feature belongs to which EAPI. I freely admit, I |
| 14 |
do not know that. Is there a list somewhere? |
| 15 |
|
| 16 |
EAPI issues may lead to a lot of confusion and eclass bloat, especially since |
| 17 |
we still can't remove stale eclasses afaik. |
| 18 |
|
| 19 |
|
| 20 |
Carsten |
Archives