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

[Brian Harring]

On Mon, Mar 19, 2012 at 02:36:34PM +1300, Kent Fredric wrote:
> On 19 March 2012 14:12, Steven J Long <slong@××××××××××××××××××.uk> wrote:
> >
> > As for non-bash ebuilds, I have always agreed with antarus that they should
> > simply use a different extension. Adding a new extension per source language
> > is a *lot* cleaner than one per EAPI.
>
> Ok: If we take this notion and enshrine it in stone:
>
> If we assume Bash 4 is a seperate language from Bash 3, as its
> syntax-backwards-incompatible, is it fair to suggest that for some
> future EAPI which require Bash 4, that the extension change to suit?
>
> ie:  move from .ebuild  to .ebuild4 , where '.ebuild' conveys the
> format is bash, and that '.ebuild4' is bash4 only?
>
> That way you have a forwards declaration of the syntax/file format
> required to parse the file, but no declaration of the EAPI, so you're
> not breaking encapsulation.
>
> This is breaking the direct file==eapi connection, but still
> maintaining a loose file<->eapi connection.
>
> Its /sort/ of like the "one time extension change" proposal, except
> its less 'arbitrary' than something like .eb , and it gives us the
> future option of changing the suffix again if bash 5 comes out with
> different syntax.
>
> Then we can do
>
> .ebuild = EAPI 0 - 4    & bash >= 3
> .ebuild4 = EAPI5 - 9    & bash >= 4
> .ebuild5 = EAPI10 - 15 & bash >= 5
>
> Thoughts?

This is a bad idea; it arbitrarily bleeds the bash version into the 
ebuild name, still requires an EAPI mechanism w/in the actual file, 
and is likely to break tools that have assumptions about extensions 
(even ones sooner or later written against such a setup).

Besides; it's not bash version as much as global scope settings, 
functions, etc, that are the issue.

Syntax is generally minor in comparison.
~harring