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

[Michał Górny]

On Wed, 7 Mar 2012 21:41:02 +0100
Ulrich Mueller <ulm@g.o> wrote:

> *** Proposal 1: "Parse the EAPI assignment statement" ***
>
> [...]
>
> Written in a more formal way, appropriate for a specification:
> - Ebuilds must contain at most one EAPI assignment statement.
> - It must occur within the first N lines of the ebuild (N=10 and N=30
>   have been suggested).
> - The statement must match the following regular expression (extended
>   regexp syntax):
>   ^[ \t]*EAPI=(['"]?)([A-Za-z0-9._+-]*)\1[ \t]*(#.*)?$

I'd make the regexp less strict -- at least allow whitespace around '='.
If the intent is to not rely on a specific bash version for a global
scope, why should we limit it to the (current) bash syntax?

And it may be also a good idea to not rely on a specific line format,
so e.g. 'dnl EAPI=4' will work as well.

> 1b) It is only applied for EAPI 5 and later (which means that the
>     result of the EAPI parsing would be discarded for earlier EAPIs).

Err... so what happens if 'new parsing' detects EAPI 4 and 'old
parsing' detects EAPI 5? Or more exactly, how does it know when
an older EAPI is used if it is supposed to not use the value it uses to
detect EAPI?

> *** Proposal 2: "EAPI in header comment" ***
>
> A different approach would be to specify the EAPI in a specially
> formatted comment in the ebuild's header. No syntax has been suggested
> yet, but I believe that the following would work as a specification:
> - The EAPI must be declared in a special comment in the first line of
>   the ebuild's header, as follows:
> - The first line of the ebuild must contain the word "ebuild",
>   followed by whitespace, followed by the EAPI, followed by
>   end-of-line or whitespace.

What if we ever decide to use a language which would would have another
requirements for first line?

> Again, the proposal comes in two variants:
> 2a) It is combined with a one time change of the file extension, like
>     .ebuild -> .eb.

And we're going to retroactively migrate the tree or have random file
suffixes intermixed? Not to mention we're either keeping two different
variants for a longer while, or disregarding backwards compatibility
with older package managers for no actual benefit.

-- 
Best regards,
Michał Górny