On Tue, Aug 30, 2005 at 04:47:51PM +0200, Paul de Vrieze wrote: > 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.
There actually is an ordering to the versions though- they're going to map out to later portage releases (eapi3 release's portage version >= eapi4 release's portage version >= eapi5 releases' portage version). Why am I being so damned stubborn about numbers for this? Cause I don't want users having to dink around with knowing that eapi="really cool version" somehow maps out to 3.1. Further, eapi version *likely* will wind up as the slotting for any split out portage-ebuild package, and slots traditionally have always been ints. > 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. The slotting comment above is in regard to it. People will hit annoyances along the way, but slot==EAPI for portage-ebuild ought to allow a sane resolver to dig it's way back. Won't work for stable, due to the fact stable's resolver isn't smart enough, but rewrite's should support the "lets hop from portage version to portage version in upgrading" bit. Aside from that, EAPI is specific to *ebuilds*. New format is a seperate beast that shouldn't be shoe horned into ebuilds imo. > > 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). Yielding on this, since I agree on it. Will update the next round of patches so it's stricter. > > 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. Wouldn't call it broken behaviour; the reasoning behind doing this is that people, regardless of any warning we give them, *will* have caches that are used by multiple portage versions. Bad setups will results in older portage installations updating a central cache; the negating allows for older portage installations and newer to play nice in the cache, not pissing each other off as occurs with stable and >=2.1 (or any cache change for that matter). Granted that's a combination of flat_hash and eapi, but eapi's negation still is a major factor in the compatibility. > 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. Flattening the EAPI version down to 0 is wrong; re: "" existing, it gets corrected by the layers that wrap the cache so it always winds up as a number.
pgpFiRIUIa6qE.pgp
Description: PGP signature
