Re: [gentoo-portage-dev] PATCH: initial EAPI awareness

[Paul de Vrieze]

On Wednesday 31 August 2005 01:46, Brian Harring wrote:
> > 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).

Of course there is some kind of ordering. My point is that this ordering 
should be for users only, but portage should totally disregard this.

> 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.

I don't mind you using numbers or something like "3.1-strict" meaning that 
it was introduced with portage 3.1. Just do it in such a way that when in 
the future it is decided that text can be in EAPI specifiers, portage 
will not choke on newer ebuilds that do that.

> > 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.

My main focus is not on automatic finding of compatible versions of 
portage for an EAPI value. It is on ensuring forward compatibility. This 
is easiest when portage makes very few assumptions on the contents of 
EAPI.

> 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.

EAPI defines which format the ebuild/eclass has. Whether that is a small 
change or a big change is not that relevant. Currently the formats all 
have bash-compatible syntax, and I don't argue to remove that. I just 
want to keep it possible as long as EAPI is recognizable, and bash 
doesn't bail out on it too early. Hence the reason that I argue that EAPI 
should be the first item after the whitelines and comments in an ebuild. 
This allows *fast* and failsafe detection of the required EAPI. Even when 
what follows is totally incompatible with the default parser. (bash 
is/contains also a parser)

> > > 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.

This would mean that "-" as the first character in an EAPI string should 
be disallowed until we can be "certain" that the portage versions in use 
do not need this feature anymore.

> > 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.

Why does the cache do that. It doesn't with IUSE, DEPENDS, and most other 
variables. It should be easy to have it have the same functioning with 
EAPI. Btw. if it only maps unset or "" to 0 I have no problem with that, 
but if it maps "funky-no_number%string" to 0 or any number that would be 
broken.

Paul

ps. My point is that one never knows what the future holds. The EAPI 
feature is one that must be as forward compatible as possible. Designing 
forward compatibility is hard. As such the contents of EAPI should be as 
free as possible, and retrieving EAPI should be as easy as possible (by 
putting it in the start of the file).

pps. For being able to state that one eclass/ebuild is compatible with two 
(overlapping) formats I also argue to make EAPI a space separated list of 
supported API's. As an example for why this would make sense take for 
example the depend.apache eclass. This eclass is compatible with both the 
proposed EAPI1 as the current EAPI0 as it does not use/provide 
src_compile. Writing separate eclasses with just different EAPI versions 
is rather pointless, so allowing a list of supported ones makes sense. I 
do realise that this makes things a bit harder as first the EAPI of an 
ebuild(including it's eclasses) must be decided, and only then might 
proper parsing be possible to happen.

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@g.o
Homepage: http://www.devrieze.net