* Re: [gentoo-dev] eapi function (Was: Collecting opinions about GLEP 55 and alternatives)
@ 2009-02-26 0:02 99% ` Brian Harring
0 siblings, 0 replies; 1+ results
From: Brian Harring @ 2009-02-26 0:02 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 2843 bytes --]
On Wed, Feb 25, 2009 at 11:03:07PM +0000, Ciaran McCreesh wrote:
> On Wed, 25 Feb 2009 04:49:51 -0800
> Brian Harring <ferringb@gmail.com> wrote:
> > 4) eapi as a function; instead of "EAPI=1", do "eapi 1", required as
> > the first statement (simplest way).
>
> Doesn't solve anything over having it as a variable, and has a messy
> upgrade path.
>
> > - global scope changes can occur (inherit mechanism changes
> > included).
>
> Global scope changes can no more occur than they can with it as a
> variable. All it does is changes where the barfing occurs to slightly
> earlier on.
Bullshit. First invocation of the ebuild, that means it can do
whatever it wants to the environment- literally swapping in the EAPI
environment right then/there. Auto inherits, changing the inherit
mechanism, everything (this includes shopt adjustments).
Not even sure why you're arguing that one, but back it up w/ examples
if you want to continue that line of FUD.
> > - transition is slightly icky; basically one of the following is
> > required-
> > a) for EAPI>=2, do 'eapi 3 || die "upgrade your manager"'. Reason
> > for this is that current managers obviously lack an eapi
> > function, to make managers available *now* blow up the || die is
> > required. This solution can be deployed now, no transition required
> > although at some point stating "eapi is required retroactively for
> > all eapis" would be wise to eliminate the need for the || die (cut
> > support basically for old managers)
>
> Global scope die is very very messy. This leaks out to users in the
> form of horrible messages that make the user think something's badly
> broken.
One would think "upgrade your manager" would be... self explanatory.
Regardless, spelling it out- the user visible barf is only visible on
existant managers.
For any manager supporting eapi>2 (thus having the function), the
function can exist out cleanly (no stderr complaints) from sourcing at
that point without issue.
> > b) bashrc trickery, defines an eapi if it's unset. Said eapi
> > function exports EAPI=$1, optionally triggering a die if the eapi
> > isn't 0,1,2 (since any later eapi would require a manager upgrade
> > which would also have the eapi function).
>
> Unportable, and still leaks out to users.
Two options were given there; one 'leaks out to users', the other is
the old behaviour (eapi env setting)- again, this is only visible for
the window of pre eapi 3 managers, meaning it's a one time hit (rather
then continual as you're implying).
Every proposal has uglyness- g55 for example doesn't give the user any
indication that they're not seeing ebuilds due to EAPI (in other words
loss of functionality that exists now).
~brian
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2009-02-24 22:21 [gentoo-dev] Collecting opinions about GLEP 55 and alternatives Petteri Räty
2009-02-25 12:49 ` Brian Harring
2009-02-25 23:03 ` [gentoo-dev] eapi function (Was: Collecting opinions about GLEP 55 and alternatives) Ciaran McCreesh
2009-02-26 0:02 99% ` Brian Harring
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox