Re: [gentoo-pms] EAPI specification in ebuilds

[Ulrich Mueller]

>>>>> On Sun, 13 May 2012, David Leverton wrote:

> Apologies for not noticing these sooner, but now that I come to
> implement it...

>> +\begin{verbatim}
>> +^[ \t]*EAPI=(['"]?)([A-Za-z0-9+_.-]*)\1[ \t]*(#.*)?$
>> +\end{verbatim}

> 1) Should an empty value be allowed here?

That was the intention, because the spec says that an empty value is
equivalent to 0.

> 2) If there's a trailing comment it needs to have at least one
> whitespace between it and the end of the value:

>      [dleverton@shiny-one pms] $ EAPI=123#foo
>      [dleverton@shiny-one pms] $ echo ${EAPI}
>      123#foo

Darn. So we need another [ \t] in the last subexpression:

-^[ \t]*EAPI=(['"]?)([A-Za-z0-9+_.-]*)\1[ \t]*(#.*)?$
+^[ \t]*EAPI=(['"]?)([A-Za-z0-9+_.-]*)\1[ \t]*([ \t]#.*)?$

>> +The package manager may optionally determine the EAPI of an ebuild by parsing its first non-blank
>> +and non-comment line, using above regular expression. If a recognised EAPI has been determined
>> +such, then the package manager must make sure that the \t{EAPI} value obtained by sourcing the
>> +ebuild with bash is identical to the EAPI obtained by parsing. The ebuild must be treated as
>> +invalid if these values are different.

> 3) If the first non-blank non-comment /doesn't/ match the magic regexp,
> should the PM insist that the post-source EAPI is 0 (or unset), or
> should it accept whatever it gets?

The former. If the first non-blank non-comment doesn't match the
regexp, then the EAPI determined by parsing is 0 (or empty, which is
equivalent).

Do we need to clarify the wording here? (Patches are welcome.)

Ulrich