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: Zac Medico <zmedico@g.o>
Subject: Re: RFD: EAPI specification in ebuilds
Date: Sun, 11 Mar 2012 21:08:24 -0700
On 03/11/2012 06:55 PM, Brian Harring wrote:
> On Sat, Mar 10, 2012 at 08:06:50AM -0800, Zac Medico wrote:
>> 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.

There are a couple of other cases worth considering:

1) User downloads an overlay that doesn't provide cache. We want the
package manager to give a pretty "EAPI unsupported" message, rather than
spit out some bash syntax errors.

2) You're assuming that a package manager can validate cache for an EAPI
that it doesn't necessarily support. That's a somewhat fragile
assumption, given the complexities of cache validation, which involve
verification all files that affect metadata and those files may vary
depending on the EAPI.

> 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.

For the sake of being robust in all possible cases, it's just a lot
simpler if we can obtain the EAPI simply and reliably, without spawning
bash to source the ebuild.

> Also, stop referencing wikipedia.  People know what "trivial 
> objection" and "KISS" is.

You can't assume that. On this list we've got potential to have readers
and responders with lots of different backgrounds. Your insistence on
using bash to obtain the EAPI would make me wonder if you understood the
KISS principle, if I didn't know you better.
-- 
Thanks,
Zac


Replies:
Re: RFD: EAPI specification in ebuilds
-- Brian Harring
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
Re: RFD: EAPI specification in ebuilds
-- Brian Harring
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.