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