Re: [gentoo-portage-dev] [PATCH] EAPI cleanups and fixes

[Brian Harring]

On Tue, Oct 04, 2005 at 08:27:09AM +0900, Jason Stubbs wrote:
> On Tuesday 04 October 2005 03:30, Brian Harring wrote:
> > On Tue, Oct 04, 2005 at 01:06:35AM +0900, Jason Stubbs wrote:
> > > Don't like the size of this patch, but it's quite repetitive so...
> >
> > Wouldn't worry on the repetitive, it's repetitive due to the fact the
> > *dbapi classes don't (ab|)use inheritance...
> >
> > > * Make all aux_get() functions return a list of strings again
> >
> > Why is this a good thing for EAPI?
>
> Consistency. There is no mapping of names to types so any tool that uses
> aux_get to enumerate values and assumes that they are strings (as they have
> always been and still are for every other key) would break.

What tools are querying EAPI via aux_get already?  I'm not much for 
making it a string purely because everything else is strings.


> > > * Move the EAPI validity check into a separate function
> > > * Raise a specific UnsupportedAPIException instead of plain Exception

> No problem with these two?
Cleaner, so nope, no complaints.


> > > * Mark metadata of unsupported EAPIs as "INVALID" rather than -1
> >
> > This doesn't really fly imo. You mark it as invalid, and _no_ portage
> > version (regardless of it's ability to handle that EAPI) will _ever_
> > regenerate that entry.
> >
> > An old portage version updating the cache would make certain nodes
> > never usable.
> >
> > The -1 is wrong, should be -EAPI.
>
> So negative numbers signals invalid cache entries in the scheme?

sort of.  Indication of what EAPI capable portage is needed that is 
capable of regenerating that entry correctly.

This gets back to why the original patch was doing >=0 tests.

> > This however is getting back into
> > the "eapi should be freeform, not just ints", which I thought I
> > clarified why it should be ints (or people shut up instead of
> > listening to me argue it). :)
>
> The only reasoning that I recall without checking is that it wouldn't
> complicate certain code paths. That's not a valid reason, in my opinion.
>
> Can leave that debate alone though. s/INVALID/\-1/ in the patch works for me.

-EAPI... -1 implies 3.x would be capable of regenerating it (may not 
be the case).

It was partially code simplicity, but moreso it's sanity from where I 
sit.  Refinements of specs, packages, projects, whatever, is numerical 
and increasing to indicate later revisions.
EAPI="the horny toad" ain't going to happen (nor should it), imo.
~harring