1 |
On 03/09/2012 11:20 AM, Ciaran McCreesh wrote: |
2 |
> On Fri, 09 Mar 2012 11:49:44 -0500 |
3 |
> Michael Orlitzky <michael@××××××××.com> wrote: |
4 |
>>>> isnt the whole point of the proposal to get eapi without sourcing ? |
5 |
>>>> |
6 |
>>>> so that we can use new bash features at local or global scope |
7 |
>>>> without risking that people with an old bash get syntax errors |
8 |
>>>> trying to get the eapi |
9 |
>>> |
10 |
>>> Right. Michael has lost sight of the goal and is moving off on a |
11 |
>>> tangent. |
12 |
>> |
13 |
>> The point was to be able to get the EAPI without crashing if the |
14 |
>> ebuild uses newer features. |
15 |
> |
16 |
> No, it's not. There's more to it than that. |
17 |
> |
18 |
> Some EAPIs really require defining certain environment variables, shell |
19 |
> options, sandbox things etc *before* the sourcing starts. It's a massive |
20 |
> pain in the ass to try to handle setting that kind of thing on the fly |
21 |
> once the sourcing has already started. Knowing the EAPI before having |
22 |
> to spawn a bash process isn't just about performance, it's also about |
23 |
> making ebuilds much less difficult to deal with. |
24 |
|
25 |
Yeah. Another way of putting it is that the requirement to spawn a bash |
26 |
process and source the ebuild adds a ridiculous amount of unnecessary |
27 |
complexity, in violation of the KISS principle [1]. |
28 |
|
29 |
[1] http://en.wikipedia.org/wiki/KISS_principle |
30 |
-- |
31 |
Thanks, |
32 |
Zac |