1 |
On 03/09/12 10:58, Zac Medico wrote: |
2 |
> On 03/09/2012 07:51 AM, Alexis Ballier wrote: |
3 |
>> On Fri, 09 Mar 2012 07:41:09 -0800 |
4 |
>> Zac Medico <zmedico@g.o> wrote: |
5 |
>> |
6 |
>>> On 03/09/2012 07:21 AM, Michael Orlitzky wrote: |
7 |
>>>> The advantage that the eapi function has over a comment is that |
8 |
>>>> it's not magic -- it's just normal bash syntax. So we've addressed |
9 |
>>>> that issue at a small performance cost (we're really only sourcing |
10 |
>>>> the ebuild up to 'exit'). |
11 |
>>> |
12 |
>>> Also consider the case where a user syncs after not having updated |
13 |
>>> for a couple of months, and the tree contains some ebuilds with EAPIs |
14 |
>>> that are not supported by the currently installed package manager. |
15 |
>>> |
16 |
>>> In this case, when resolving dependencies and filtering ebuilds based |
17 |
>>> on whether or not their EAPI is supported, spawning bash once per |
18 |
>>> ebuild is much more costly than the alternatives. |
19 |
>> |
20 |
>> isnt the whole point of the proposal to get eapi without sourcing ? |
21 |
>> |
22 |
>> so that we can use new bash features at local or global scope without |
23 |
>> risking that people with an old bash get syntax errors trying to get |
24 |
>> the eapi |
25 |
> |
26 |
> Right. Michael has lost sight of the goal and is moving off on a tangent. |
27 |
|
28 |
The point was to be able to get the EAPI without crashing if the ebuild |
29 |
uses newer features. If you can get the EAPI without sourcing, that |
30 |
obviously accomplishes the goal. But there are other goals, too, like |
31 |
not limiting the syntax of the EAPI assignment. I was just trying to |
32 |
think up something that addresses them all. |
33 |
|
34 |
In any case, yeah, it would crash and burn if someone synced his tree |
35 |
with an ancient version of portage. But so would the comment solution. |
36 |
If you want to fix that, we either have to rename everything (and hope |
37 |
we get it right this time) or reconsider GLEP 55. |