| 1 |
On Tue, Aug 30, 2005 at 03:15:15PM +0200, Marius Mauch wrote: |
| 2 |
> On 08/30/05 Brian Harring wrote: |
| 3 |
> Problem is that you then rely on python always evaluating "somestring" > |
| 4 |
> 0 as True which I don't think is a good idea (it holds true even for "0" |
| 5 |
> > 0), if you treat 0 as a string you get problems (as some strings are |
| 6 |
> > "smaller" than 0) and you can't convert all strings to ints. |
| 7 |
|
| 8 |
In the initial proposal of EAPI, it was intended as version ebuild |
| 9 |
format #; think format specifications. |
| 10 |
|
| 11 |
Float is probably better, but strings being slipped in I don't see any |
| 12 |
good reason to allow, nor has it been requrested (it was |
| 13 |
specifically ixnayed when the idea was hashed out actually). |
| 14 |
|
| 15 |
Aside from that, again, stable is capable of a single eapi version; if |
| 16 |
it's a string, the code catches the value error and knocks it down to |
| 17 |
eapi0 due to the reasons described above. |
| 18 |
|
| 19 |
Further reason why string is a no go indicated in the code; if eapi0 |
| 20 |
portage tries regening an eapi1 cache entry, it stores negated eapi |
| 21 |
version with no other metadata. Allowing strings nukes that approach, |
| 22 |
unless you disallow - as the first character (which would be |
| 23 |
demonstration of strings not being incredibly well suited for eapi |
| 24 |
settings imo). |
| 25 |
|
| 26 |
> What's the point of using > anyway? |
| 27 |
Simplicity in the code right now, since stable will *never* support |
| 28 |
anything but eapi0. It's an easy check. |
| 29 |
|
| 30 |
~harring |
Archives