Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Michael Orlitzky <michael@...>
Subject: Re: RFD: EAPI specification in ebuilds
Date: Fri, 09 Mar 2012 11:49:44 -0500
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@g.o> 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.


Replies:
Re: RFD: EAPI specification in ebuilds
-- Zac Medico
References:
RFD: EAPI specification in ebuilds
-- Ulrich Mueller
Re: RFD: EAPI specification in ebuilds
-- Michael Orlitzky
Re: RFD: EAPI specification in ebuilds
-- Michał Górny
Re: RFD: EAPI specification in ebuilds
-- Michael Orlitzky
Re: RFD: EAPI specification in ebuilds
-- Michał Górny
Re: RFD: EAPI specification in ebuilds
-- Michael Orlitzky
Re: RFD: EAPI specification in ebuilds
-- Ciaran McCreesh
Re: RFD: EAPI specification in ebuilds
-- Michael Orlitzky
Re: RFD: EAPI specification in ebuilds
-- Ciaran McCreesh
Re: RFD: EAPI specification in ebuilds
-- Michael Orlitzky
Re: RFD: EAPI specification in ebuilds
-- Michał Górny
Re: RFD: EAPI specification in ebuilds
-- Michael Orlitzky
Re: RFD: EAPI specification in ebuilds
-- Zac Medico
Re: RFD: EAPI specification in ebuilds
-- Michael Orlitzky
Re: RFD: EAPI specification in ebuilds
-- Michael Orlitzky
Re: RFD: EAPI specification in ebuilds
-- Zac Medico
Re: RFD: EAPI specification in ebuilds
-- Alexis Ballier
Re: RFD: EAPI specification in ebuilds
-- Zac Medico
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: RFD: EAPI specification in ebuilds
Next by thread:
Re: RFD: EAPI specification in ebuilds
Previous by date:
Re: RFD: EAPI specification in ebuilds
Next by date:
Re: RFD: EAPI specification in ebuilds


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.