On Mon, Mar 19, 2012 at 02:36:34PM +1300, Kent Fredric wrote: > On 19 March 2012 14:12, Steven J Long <sl...@rathaus.eclipse.co.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
