| 1 |
On Mon, 23 Feb 2009 17:06:17 +0100 |
| 2 |
Peter Alfredsen <loki_val@g.o> wrote: |
| 3 |
> To be honest I see no good reason for allowing manipulation of it, but |
| 4 |
> I'm sure other people will tell me why adding this requirement at this |
| 5 |
> point is wrong |
| 6 |
|
| 7 |
There's not really a good reason to allow manipulating it (and, |
| 8 |
obviously, with GLEP 55 manipulating it becomes impossible), but since |
| 9 |
for all current EAPIs it's just defined as a metadata variable that's |
| 10 |
generated in the same way as things like SLOT, manipulating it is |
| 11 |
unfortunately legal. |
| 12 |
|
| 13 |
> even though no ebuilds in the tree to the best of my knowledge use |
| 14 |
> EAPI as anything more than a declaration that's placed Just before |
| 15 |
> inherit, right after the header. |
| 16 |
|
| 17 |
People have, in the past, set EAPI inside eclasses. It's stupid and |
| 18 |
horrible, but they've done it. |
| 19 |
|
| 20 |
But here's the thing -- even if we retroactively enforce a new rule |
| 21 |
requiring it to be specified in a particular way right after the header |
| 22 |
(which is bad, since it breaks things people have already done), it |
| 23 |
*still* doesn't let us change global scope behaviour since current |
| 24 |
package managers don't extract EAPI the horrid way. |
| 25 |
|
| 26 |
-- |
| 27 |
Ciaran McCreesh |
Archives