On Mon, Mar 12, 2012 at 09:05:26AM -0700, Zac Medico wrote:
> On 03/12/2012 01:36 AM, Brian Harring wrote:
> > On Sun, Mar 11, 2012 at 09:08:24PM -0700, Zac Medico wrote:
> >> 1) User downloads an overlay that doesn't provide cache. We want the
> >> package manager to give a pretty "EAPI unsupported" message, rather than
> >> spit out some bash syntax errors.
> > 
> > This criticsm pretty much applies *strictly to the existing 
> > implementation*.  It's disenguous busting it in this fashion.
> > 
> > EAPI as a function explicitly gives it an out before hitting any of 
> > that, eliminating your entire critique.  Same goes for parsing it out 
> > of the ebuild, or renaming the extension.
> 
> You're assuming that the ebuild calls your eapi() function before it
> uses any syntax that's unsupported by the user's installed version of bash.

A bit, although that's a pretty valid assumption frankly.  For current 
bash syntax, the only thing they could do that would cause issues is 
bash regex's for example- which if they have regex's prior to the eapi 
invocation, they're doing something stupid anyways.

Regardless, detecting and suppressing isn't too hard- start sourcing 
w/ `set -e`, disabling that once `eapi` has been invoked for example.  
Pretty sure people will scream "that's horrible", but it's 
surprisingly effective.


> > 1) PM still doesn't support that EAPI, looks at the cache/ebuild: 
> > checksums are the same, thus the stored EAPI is trustable, leading to 
> > the PM knowing it still can't process that ebuild and masking it 
> > appropriately.
> 
> You're assuming that cache is provided by the repo,

Sigh.  I'm making no such assumptions, nor would I; it's a stupid line 
of thought.

All of this has to function in the absence of a cache, and that's a 
core usage scenario.


> which is not
> guaranteed, depending on the source. Even if the cache does exist, then
> you're assuming it's in a format that the package manager can reliably
> parse the EAPI from, even though that EAPI may not be supported. That
> may or may not reliable assumption, and having a pre-defined protocol to
> directly obtain the EAPI without using the cache is much more reliable.

This is a nonstatement.  To deal w/ the cache (validate it) you have 
to be able to reliably pull EAPI out of the ebuild.

That's what this whole fucking discussion is about; really not sure 
why you're trying to argue this point against eapi as a function.  As 
I already laid out, it can deal w/it, same as the rest.  Importantly,
the approach can also work across the transition period preventing 
current-day PMs (using current EAPI mechanisms) from breaking when 
used against later EAPIs that were released via `eapi as a function`.


> > What I'd like to see, is accuracy in this discussion.  Skip the 
> > handwavey "complexity! complexity! complexity!" crap, same for 
> > selective robustness definitions.  Past attempts at this discussion 
> > mostly failed due to people pulling crap like this and frankly it just 
> > pisses people off. 
> 
> It's just a symptom of people not abiding by the KISS principle. When
> you start talking about an approach such as the "eapi() function"
> approach which introduces lots of unnecessary complexity, it naturally
> makes the whole discussion more complex and hand-wavey.

With respect; you're proposing we go gum up version parsing via 
shoving EAPI directly into it.  Literally, make what is already a 
complex mess, worse.  Apply some KISS to your proposal please. ;)

Just hammering the point home; compatibility *is* complex.  Claiming 
otherwise is naive.  Case in point: your proposal breaks the shit out 
of any current-day package manager that saw such a filename.

I really have a hard time reading your posts when basic issues like 
that aren't paid attention to, but you've no problems claiming 
complexity/brokenness in other proposals.

As I said, I'd like to see some accuracy; not hand wavy buzzwords.

I'd much more like to see prototypes of peoples proposals in addition 
since at least that way they would flush out the breakages in their 
proposals (potentially dropping it in the process since some of these 
are pretty half baked).

~brian