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