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

[Steven J Long]

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?
>
I don't agree that it's a separate language: a lot of work goes into keeping 
BASH backward-compatible, so it's only when you use a new feature that your 
script will no longer work on an older version. We dealt with the move from 
bash2 to bash 3 quite well, I thought, and I don't see what's wrong with 
stipulating support for a new BASH version in a new EAPI: that seems 
quintessential use of the EAPI mechanism to me.

Another example would be use of extglob: as a scripting feature it needs to 
be enabled before any of the functions or script using it are even parsed, 
or BASH will bail with a syntax error. Specifying that it is so enabled in 
an EAPI (which I believe was done a while back) allows the ebuild author to 
use syntax that would otherwise fall over. Again, the EAPI mechanism works 
fine, and there is no need for a different extension, even though the syntax 
accepted has changed.

So we already have an example of where syntax changes, not just the 
available environment, work with an EAPI inside the file, as it should be.

> 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?
>
As Brian said, you still need an EAPI mechanism, and further you've still 
leaked metadata that simply doesn't need to be leaked. The only thing that 
has ever held up adoption of EAPI extraction using a simple EAPI="foo" 
declaration, matching tree-usage, is the fact that PMS does not specify 
which characters are allowed in an EAPI name. This was asked for a couple of 
years ago, iirc, and it is clearly necessary whether you scan for a token in 
the ebuild, or you stick EAPI into the filename. (After all you are even 
more restricted when you're talking about the filename, as opposed to a text 
string given in a script.)

It just seems like a major hole in the spec, given that EAPI is so critical 
to how you deal with the ebuild, and characters allowed for other tokens 
such as category, package, version, keywords, USE-flags etc are specified. 
It would be necessary for GLEP-55, but is not mentioned therein, which I 
guess means the GLEP is under-specified as well.

.eapi-NN just strikes me as similar to having M$ Word format as .doc95 
.doc2000 and the like- a complete mess. Or indeed sticking the charset 
encoding (which has profound consequences when reading a file) from an HTML 
file into its filename. Again, a similar, if not worse, piece of metadata-- 
just extracting it is hard if you don't know the charset in advance, but 
I've never heard of anyone arguing that it should belong anywhere other than 
in the file, from where tools dealing with it locally can extract it and, 
say, emit the correct HTTP header.

What I was referring to with an extension-per-language would be something 
like .pbuild for python-based build scripts, or .xbuild for your XML-
declarative example, and so on. In each case, you'd still need a supporting 
infrastructure, but it's clear that you are using a completely different 
setup, and it's no longer a traditional BASH-based ebuild. It would be quite 
reasonable to suppose that you'd have EAPI specified there as well, since 
you'd want to be able to add to and change the features you support over 
time. Would you really want to change the extension each time you did, 
though?

Regards,
Steve.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)