FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 02-25-2009, 11:02 PM
Brian Harring
 
Default eapi function (Was: Collecting opinions about GLEP 55 and alternatives)

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
 
Old 02-25-2009, 11:24 PM
Brian Harring
 
Default eapi function (Was: Collecting opinions about GLEP 55 and alternatives)

On Thu, Feb 26, 2009 at 12:11:04AM +0000, Ciaran McCreesh wrote:
> On Wed, 25 Feb 2009 16:02:46 -0800
> Brian Harring <ferringb@gmail.com> wrote:
> > 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.
>
> You can do that on a variable assignment too, with all the same
> implications as having it as a function, and a slightly less horrible
> upgrade path.

You're contradicting your own statements. Pkg level eclasses (if
reusing inherit) would explode 'in a user visible manner' if using var
only.

While the above wasn't FUD, definitely was misinfo. Be consistant
please.


> > > 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.
>
> Which is a "wait a year or more" thing... If you do it with a variable
> instead of a function, you can at least roll out EAPI 3 (without any
> global scope changes, but with the stricter "stop on setting an
> unsupported EAPI" requirement) without the wait.

There is no reason to wait a year let alone wait for EAPI3 to be
defined. The eapi function could be added now in preparation (thus
killing the user visible pukage), regardless of eapi 3's timeline.

The die exists strictly to be thorough about stragglers.


> > 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).
>
> Given you're a proponent of not showing users things that're merely
> masked...

Say what you want; g55 still has the flaw.

~harring
 

Thread Tools




All times are GMT. The time now is 01:26 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org