| 1 |
On 7 March 2012 21:07, Alexis Ballier <aballier@g.o> wrote: |
| 2 |
> As i understand it, $PM will need to try the regexp tingy on any ebuild |
| 3 |
> anyway, guess the EAPI then source the ebuild with the right sourcer |
| 4 |
> to get the real EAPI and compare it. |
| 5 |
|
| 6 |
Not exactly... the idea with proposal 2) is that the header comment |
| 7 |
becomes the One True Way to set the EAPI, so it wouldn't be "guessing" |
| 8 |
as such, and ebuilds wouldn't be allowed to change it during sourcing |
| 9 |
any more than they can redefine PV or the like. As mentioned, 2b) |
| 10 |
still risks a mismatch between the header and the assignment, but |
| 11 |
hopefully that would be temporary and the assignments could be dropped |
| 12 |
eventually. (And I'd suggest that the header EAPI is still considered |
| 13 |
authoritative if present - the mismatch check should probably be a |
| 14 |
hard error, or if not it should generate a warning and use the header |
| 15 |
value. There should be minimal if any risk of this changing behaviour |
| 16 |
for any existing ebuild, since existing ebuilds almost certainly won't |
| 17 |
match the chosen header syntax.) |
| 18 |
|
| 19 |
As for my opinion, I would prefer 2a), or 2b) as a second choice. |
| 20 |
IMHO it's much simpler and cleaner to come up with a strict, |
| 21 |
well-defined header format than to try and work within (an arbitrarily |
| 22 |
restricted version of) bash syntax. |
Archives