Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Michael Orlitzky <michael@orlitzky.com>]

On 03/09/12 10:58, Zac Medico wrote:
> On 03/09/2012 07:51 AM, Alexis Ballier wrote:
>> On Fri, 09 Mar 2012 07:41:09 -0800
>> Zac Medico <zmedico@gentoo.org> wrote:
>>
>>> On 03/09/2012 07:21 AM, Michael Orlitzky wrote:
>>>> The advantage that the eapi function has over a comment is that
>>>> it's not magic -- it's just normal bash syntax. So we've addressed
>>>> that issue at a small performance cost (we're really only sourcing
>>>> the ebuild up to 'exit').
>>>
>>> Also consider the case where a user syncs after not having updated
>>> for a couple of months, and the tree contains some ebuilds with EAPIs
>>> that are not supported by the currently installed package manager.
>>>
>>> In this case, when resolving dependencies and filtering ebuilds based
>>> on whether or not their EAPI is supported, spawning bash once per
>>> ebuild is much more costly than the alternatives.
>>
>> isnt the whole point of the proposal to get eapi without sourcing ?
>>
>> so that we can use new bash features at local or global scope without
>> risking that people with an old bash get syntax errors trying to get
>> the eapi
> 
> Right. Michael has lost sight of the goal and is moving off on a tangent.

The point was to be able to get the EAPI without crashing if the ebuild
uses newer features. If you can get the EAPI without sourcing, that
obviously accomplishes the goal. But there are other goals, too, like
not limiting the syntax of the EAPI assignment. I was just trying to
think up something that addresses them all.

In any case, yeah, it would crash and burn if someone synced his tree
with an ancient version of portage. But so would the comment solution.
If you want to fix that, we either have to rename everything (and hope
we get it right this time) or reconsider GLEP 55.