Re: [gentoo-dev] extending existing EAPI semantics

[Brian Harring]

You actually pretty much completely misinterpreted what I was saying, 
so inserting the example back into the email and trying again...

On Wed, Jun 11, 2008 at 12:25:55AM -0400, Mike Kelly wrote:
> Brian Harring wrote:
> >One thing I'll note is that the .ebuild-$EAPI approach isn't the end
> >all fix to versioning extensions that y'all represent it as.
> >Essentially, what .ebuild-$EAPI allows is additions to version
> >comparison rules, no subtractions.  Each new $EAPI *must* be a
> >superset of previous $EAPIs.
>
> >An example would be removal of float comparison rules; for
> ><=eapi-1, .006 < .6;  Now if eapi-2 stated .006 == .6, that
> >literally means that the PM would have to maintain versioning rules
> >per eapi level, meaning that for an eapi1 ebuild, what it would
> >match would differ from eapi2. Aside from that being a
> >cluster-fuck in the implementation, it's a cluster-fuck for the dev
> >trying to visualize what the manager is actually up to.
>
> Uhh... no. Just like how older package managers which don't understand
> how to read the EAPI from a filename suffix would basically ignore the
> new ebuilds, any package manager that can, but doesn't recognize the
> eapi of the new one, will just ignore it. It won't ever try to figure
> out its version or anything, it'll just do nothing.

Here's the scenario:

1) EAPI1 defines foo-0.006 < foo-0.6.
2) EAPI2 redefine it so that foo-0.006 == foo-0.6
3) pkg 'a' has one version- '0.006'
4) pkg b-1, EAPI=1; DEPEND='<=a-0.006'
5) pkg c-1, EAPI=2; DEPEND='>=a-0.6'

Now, via EAPI1 definition, b-1 *must* match a-0.006; via EAPI2 
definition, b-2 *must* match a-0.006 also.  The only way the manager 
can properly support this request is via getting the EAPI from the pkg 
that specified that request.

Literally, the ordering of matches would have to vary dependant upon 
the eapi of the pkg.  This is a serious cluster fuck for any 
implementation, and it's a pretty nice gotcha for ebuild developers.

The sane alternative here is that each successive EAPI release, 
specifically the versioning rules, must be a superset of existing.  
Via that you can induce a total ordering that works regardless of the 
EAPI level of the generating pkg.

A scenario that is far more entertaining is how the manager is 
supposed to handle the following:

1) EAPI2 defines 1.0-scm > 1.0
2) pkg 'a' has one visible version; 1.0-scm
3) pkg b-1 EAPI=1, DEPEND='<=a-1'
4) pkg c-1 EAPI=2, DEPEND='a'

What is the correct result here?  Since b-1's versioning rules don't 
know a damn thing about -scm, should it even be possible for it to use 
that version?  The only valid solution here (since EAPI1 does not 
know, nor specify the ordering of -scm) is to bail.

If you're maintaing a total ordering (each EAPI a superset of the 
last for versioning rules), you *could* retroactively decide on that 
case.

Either way, point is that .ebuild-$EAPI doesn't magically solve 
versioning changes.  It hides away user visibility of it, but doesn't 
solve the real issue.


> Also, there is absolutely no reason for all future EAPIs to be a
> superset of old eapis.

.ebuild-$EAPI-n requires all *versioning rules* to be a superset of 
$EAPI=(n-1); if in doubt, re-read my example above.

Non versioning rules of $EAPI, no, no requirement to be supersets of 
proceeding- but versioning under .ebuild-$EAPI, yes, it's required.

Cheers,
~harring