Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Brian Harring <ferringb@gmail.com>]

On Fri, Mar 09, 2012 at 09:47:50AM -0800, Zac Medico wrote:
> On 03/09/2012 09:31 AM, Michael Orlitzky wrote:
> > On 03/09/12 12:11, Ulrich Mueller wrote:
> >>>>>>> On Fri, 09 Mar 2012, Michael Orlitzky wrote:
> >>
> >>>> What if bash starts to parse the script completely and barfs at
> >>>> 'syntax error' before it starts executing stuff?
> >>
> >>> It doesn't parse the script completely, it executes line-by-line, so
> >>> we can bail out early.
> >>
> >> How can you tell that this behaviour won't be changed in a future bash
> >> version?
> >>
> > 
> > Who's to say that in the future my computer won't be made out of
> > delicious ice cream, eliminating the need for EAPIs entirely?
> > 
> > Chances are, this would break thousands of scripts, so we hope they
> > wouldn't do it. If it does happen, we either deal with it then, or don't
> > upgrade to that version of bash -- the same as we would do with any
> > other massive breaking change.
> 
> Ulrich is talking about extensions which require a newer version of
> bash. These kinds of extensions are quite common and don't cause
> "massive breaking" because people simply have to upgrade bash in order
> to use the new extensions, and their old scripts continue to run because
> the new extensions don't interfere with backward compatibility.
> 
> Your eapi() function proposal is especially fragile in this context
> because it assumes that the installed version of bash will be able to
> execute a script that may target a newer version of bash. This is a
> special case that is typically not a problem, although it is a major
> problem under the specific conditions that your eapi() function approach
> induces.

Pragmatic reality, the eapi function actually would work fine.  As 
pointed out elsewhere, bash parses as it goes- which isn't going to 
change.

If someone invokes 'eapi happy-meal' and it's not supported, 
the sourcing is stopped immediately, cache gets -happy-meal for the 
EAPI, and the pm continues to ignore the ebuild till either the 
ebuilds mtime changes (which case it redoes the metadata regen) or the 
PM now supports that EAPI, and... you guessed it, redoes the metadata 
regen.  The cache behaviour is basically the same regardless of the 
EAPI mechanism.

Now, this isn't to say everyone views the function as *optimal*.  
People can argue about that as much as they'd like.

The point however is that it *would* work.  Anyone claiming 
fragility/otherwise needs to put forth actual code examples.


> Anyway, lets focus on our main goal, which is to decide on a way to
> obtain the EAPI _without_ sourcing the ebuild.

Nitpicking, but the point needs be made; this is *your* requirement.  
The requirement is to be able to deploy new globals/bash 
requirements/whatever.

There is a difference.

~brian