On 03/09/12 12:47, Zac Medico wrote: > > Ulrich is talking about extensions which require a newer version of > bash. These kinds of extensions are quite common and don't cause > "massive breaking" because people simply have to upgrade bash in order > to use the new extensions, and their old scripts continue to run because > the new extensions don't interfere with backward compatibility. > > Your eapi() function proposal is especially fragile in this context > because it assumes that the installed version of bash will be able to > execute a script that may target a newer version of bash. This is a > special case that is typically not a problem, although it is a major > problem under the specific conditions that your eapi() function approach > induces.
Well, you wouldn't need to execute the script targeting a newer version of bash. You would need to source it, which involves maybe setting EAPI=5, and then calling the 'eapi' function which will immediately exit. The new features aren't a problem because you never get to them. (If you try to use some new bash extension to compute your EAPI value, well, you shouldn't have done that.) > Anyway, lets focus on our main goal, which is to decide on a way to > obtain the EAPI _without_ sourcing the ebuild. Agreed. I'm forced to agree with Ciaran: can we just ignore the previous council's decision, and reconsider the merits of GLEP 55?
