-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I realize that I'm asking this very late in the discussion, so please
bear with me if it has been hashed before.

On Thu, May 14, 2009 at 11:16:23PM +0200, Peter Alfredsen wrote:
> We need a mechanism to be able to use newer bash-features in ebuilds.
> Preferably one that doesn't go "Wait a couple of years, hope
> everyone did X then Just Do it." We want one that goes like "Get a new
> EAPI approved with new minimum bash-version attached, start using cool
> stuff like ( Bash-4.0 ):
 
 <snip>

> Personally, I like the first version better. It would be cool if we
> could start using it sooner. GLEP-55 provides the "clean" solution, by
> just making the file name indicate what's inside. No need to parse, no
> nothing. Portage is currently testing a "first line with EAPI=
> determines EAPI" method. That's slightly less clean, but has the added
> benefit of not breaking anything that relies on .ebuild extension for
> ebuilds and I think it's not an unreasonable limitation on ebuilds to
> require EAPI= to be parseable by !bash.
 
I don't know how strong this argument is, but here is my opinion about
the issue, followed up with a question.

The second solution seems to be the better one because it does not go
against standards.  For example, we see extentions like .c, .py and
.pl, instead of .c-43, .py-25 and .pl-58.  There are ways within the
languages to tell which version of the compiler is compiling them as
needed.  So, If we say that, EAPI 4, for example, requires bash-4.0,
Isn't there a way the PM could find out which version of bash is being
run, compare that to the EAPI, then take appropriate action?

- -- 
William Hubbs
gentoo accessibility team lead
williamh@g.o
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoMkdUACgkQblQW9DDEZTihowCdEynGXsB0Z1r9y43VeWEs9JLF
SrQAn2iNPikCR+tZHGyrv+ykr4y1D+81
=6F5i
-----END PGP SIGNATURE-----