| 1 |
Ulrich Mueller wrote: |
| 2 |
> Please find a new iteration of the patch below. |
| 3 |
|
| 4 |
Apologies for not noticing these sooner, but now that I come to |
| 5 |
implement it... |
| 6 |
|
| 7 |
> +\begin{verbatim} |
| 8 |
> +^[ \t]*EAPI=(['"]?)([A-Za-z0-9+_.-]*)\1[ \t]*(#.*)?$ |
| 9 |
> +\end{verbatim} |
| 10 |
|
| 11 |
1) Should an empty value be allowed here? |
| 12 |
2) If there's a trailing comment it needs to have at least one |
| 13 |
whitespace between it and the end of the value: |
| 14 |
|
| 15 |
[dleverton@shiny-one pms] $ EAPI=123#foo |
| 16 |
[dleverton@shiny-one pms] $ echo ${EAPI} |
| 17 |
123#foo |
| 18 |
|
| 19 |
> +The package manager may optionally determine the EAPI of an ebuild by parsing its first non-blank |
| 20 |
> +and non-comment line, using above regular expression. If a recognised EAPI has been determined |
| 21 |
> +such, then the package manager must make sure that the \t{EAPI} value obtained by sourcing the |
| 22 |
> +ebuild with bash is identical to the EAPI obtained by parsing. The ebuild must be treated as |
| 23 |
> +invalid if these values are different. |
| 24 |
|
| 25 |
3) If the first non-blank non-comment /doesn't/ match the magic regexp, |
| 26 |
should the PM insist that the post-source EAPI is 0 (or unset), or |
| 27 |
should it accept whatever it gets? |
Archives