On Tuesday 30 August 2005 15:28, Brian Harring wrote: > On Tue, Aug 30, 2005 at 03:15:15PM +0200, Marius Mauch wrote: > > On 08/30/05 Brian Harring wrote: > > Problem is that you then rely on python always evaluating > > "somestring" > 0 as True which I don't think is a good idea (it holds > > true even for "0" > > > > > 0), if you treat 0 as a string you get problems (as some strings > > > are "smaller" than 0) and you can't convert all strings to ints. > > In the initial proposal of EAPI, it was intended as version ebuild > format #; think format specifications. > > Float is probably better, but strings being slipped in I don't see any > good reason to allow, nor has it been requrested (it was > specifically ixnayed when the idea was hashed out actually).
What the format of the values of EAPI is is irrelevant. The matter is that there is no way to know that version 5 is in any way compatible with version 4, which in turn is also incompatible with version 3. Seeing versions as numbers would imply an ordering in the versions. Such an ordering would seem to imply compatibility or something the like, while versions could differ significantly. As any portage version should still check which EAPI the ebuild has to be able to support it correctly any range checks would be moot anyway. About the ordering, what if there was some new format that would enable to very easilly write packages for perl modules but sucked at anything else? This would be a different format alltogether, not a different version. If EAPI's were more than just strings, at some point it might even be possible to associate packages with EAPI's so that portage would automatically signal the EAPI was unsupported, find the relevant package and merge the plugin. Restart itself and merge the ebuild that needed the new EAPI. The plugin ebuild could ensure that the portage version is compatible. > Aside from that, again, stable is capable of a single eapi version; if > it's a string, the code catches the value error and knocks it down to > eapi0 due to the reasons described above. Then the code is broken. It should check whether the value is "0" or the empty string "" or unset. If it is the latter it should change it to "0", if it is anything else it should just treat it as an unsupported format and ignore that particular ebuild. (and try to use other versions of the package that are still in the old format). > > Further reason why string is a no go indicated in the code; if eapi0 > portage tries regening an eapi1 cache entry, it stores negated eapi > version with no other metadata. Allowing strings nukes that approach, > unless you disallow - as the first character (which would be > demonstration of strings not being incredibly well suited for eapi > settings imo). As long as it does not generate "-0" this broken behaviour should not break anything as long as portage 2.1 does a forced regen or cache evaluation on installation (when detecting a 2.0 version present) or first run. > > > What's the point of using > anyway? > > Simplicity in the code right now, since stable will *never* support > anything but eapi0. It's an easy check. Is it really harder to check for either "" or unset or "0". That should be very little extra code, and would be correct regardless of future decisions regarding EAPI. EAPI should be left as free as possible, portage just needs to notice that it doesn't recognize the value. If this would be in a not-a-number exception that would be ok too. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net
pgpvLb4ccPijq.pgp
Description: PGP signature
