Re: [gentoo-dev] Re: RFD: EAPI specification in ebuilds
On Thursday 12 April 2012 15:53:07 Ulrich Mueller wrote: There is consensus in the gentoo-pms mailing list that we should tighten the rules for the position of the EAPI assignment in ebuilds, namely that it should take place in the first non-blank and non-comment line. The devmanual already requires that if you want to override the EAPI variable, you have to specify it at the top of the ebuild. In any case, the portage tree mostly complies with this. There are 130 ebuilds in 66 packages (or 0.4 % of the total number) that don't, but they can be trivially fixed (and I volunteer to do the work). do it -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFD: EAPI specification in ebuilds
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? -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );
Re: [gentoo-dev] Re: RFD: EAPI specification in ebuilds
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
