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: zmedico@g.o
From: Brian Harring <ferringb@...>
Subject: Re: RFD: EAPI specification in ebuilds
Date: Sun, 11 Mar 2012 18:55:33 -0700
On Sat, Mar 10, 2012 at 08:06:50AM -0800, Zac Medico wrote:
> On 03/09/2012 11:20 AM, Ciaran McCreesh wrote:
> > On Fri, 09 Mar 2012 11:49:44 -0500
> > Michael Orlitzky <michael@...> wrote:
> >>>> 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.
> > 
> > No, it's not. There's more to it than that.
> > 
> > Some EAPIs really require defining certain environment variables, shell
> > options, sandbox things etc *before* the sourcing starts. It's a massive
> > pain in the ass to try to handle setting that kind of thing on the fly
> > once the sourcing has already started. Knowing the EAPI before having
> > to spawn a bash process isn't just about performance, it's also about
> > making ebuilds much less difficult to deal with.
> 
> Yeah. Another way of putting it is that the requirement to spawn a bash
> process and source the ebuild adds a ridiculous amount of unnecessary
> complexity, in violation of the KISS principle [1].

This statement is incorrect.

Even if EAPI could be parsed via some non sourcing approach, we 
*still* have to source the ebuild to get the metadata for when the 
EAPI is supported (the vast majority of usage).  That complexity is 
there one way or another- we wouldn't be trying to extract the EAPI 
from the ebuild unless the cache was invalid/missing.

Phrasing it more bluntly: you can only avoid the sourcing step if you 
can isolate that the EAPI is unsupported (which is extremely rare in 
terms of actual user experience).  For the rest of the time (well past 
the 99% mark) sourcing is the immediate step following.


Also, stop referencing wikipedia.  People know what "trivial 
objection" and "KISS" is.  Pointing at random wikipedia links when
people object is just a form of fallacious argument from authority 
( http://en.wikipedia.org/wiki/Argument_from_authority ). :P

~brian


Replies:
Re: RFD: EAPI specification in ebuilds
-- Zac Medico
References:
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
Re: RFD: EAPI specification in ebuilds
-- Michael Orlitzky
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: RFC: an eclass for github snapshots?
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.