-----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 willi...@gentoo.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkoMkdUACgkQblQW9DDEZTihowCdEynGXsB0Z1r9y43VeWEs9JLF SrQAn2iNPikCR+tZHGyrv+ykr4y1D+81 =6F5i -----END PGP SIGNATURE-----
