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, 10:03 PM
Ciaran McCreesh
 
Default eapi function (Was: Collecting opinions about GLEP 55 and alternatives)

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.

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

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

This whole thing only looks neat until you think about it...

--
Ciaran McCreesh
 
Old 02-25-2009, 11:11 PM
Ciaran McCreesh
 
Default eapi function (Was: Collecting opinions about GLEP 55 and alternatives)

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.

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

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

--
Ciaran McCreesh
 
Old 02-25-2009, 11:32 PM
Ciaran McCreesh
 
Default eapi function (Was: Collecting opinions about GLEP 55 and alternatives)

On Wed, 25 Feb 2009 16:24:45 -0800
Brian Harring <ferringb@gmail.com> wrote:
> > 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.

No, if we're shoving retroactive changes into existing EAPIs (as would
be done for making eapi a function), we could instead say "EAPI must be
assigned to only once". That has *exactly* the same implications as
having it as a function, except that the upgrade path is cleaner
because there's no need for the horrid global scope die to work around
existing package managers.

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

But there's no need for the die if you do it on a variable instead of a
function.

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

Any sane package manager can, immediately upon a new EAPI being
defined, do a stable release updated with minimal information about the
new EAPI to enable it to show up as being there but not supported, even
if full support needs a new major version and lots of ~arch testing
time.

--
Ciaran McCreesh
 
Old 02-25-2009, 11:43 PM
"Jorge Manuel B. S. Vicetto"
 
Default eapi function (Was: Collecting opinions about GLEP 55 and alternatives)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> On Wed, 25 Feb 2009 16:02:46 -0800
> Brian Harring <ferringb@gmail.com> wrote:
< snip a few arguments>

Ciaran and Brian,

please respect Pettery's request and move your discussion to the GLEP55
thread or to another thread, but leave it out of this one.

Ciaran,

please stop abusing other subscribers of the dev ml.
Ultimately everyone wants a resolution to this "issue" but have
potentially different ideas of the way to go about that. So different
ideas for a solution should be encouraged, not fought.
You're obviously free to argue your case and I'm not trying to silence
you, but by replying to every and single mail in quite a few cases in a
harsh tone, you're behaving like a "bully". Please stop that.
For anyone else acting overly defensive, please remember that these are
technical discussions, so you should expect technical arguments and
having your ideas challenged. Also, everyone should be careful not to
let emotions affect their arguments.

For userrel,

- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkml5cAACgkQcAWygvVEyAKrmgCfZK4wpk0+Pc ZPCftsAyloEhDK
4DkAoJGspbLcPYb0f+FkZqVgb/kGWYhU
=SSGP
-----END PGP SIGNATURE-----
 
Old 02-25-2009, 11:51 PM
Ciaran McCreesh
 
Default eapi function (Was: Collecting opinions about GLEP 55 and alternatives)

On Wed, 25 Feb 2009 23:43:44 -0100
"Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > On Wed, 25 Feb 2009 16:02:46 -0800
> > Brian Harring <ferringb@gmail.com> wrote:
> < snip a few arguments>
>
> Ciaran and Brian,
>
> please respect Pettery's request and move your discussion to the
> GLEP55 thread or to another thread, but leave it out of this one.

This was moved to another thread, as a casual glance at the subject
would have told you.

> please stop abusing other subscribers of the dev ml.
> Ultimately everyone wants a resolution to this "issue" but have
> potentially different ideas of the way to go about that. So different
> ideas for a solution should be encouraged, not fought.
> You're obviously free to argue your case and I'm not trying to silence
> you, but by replying to every and single mail in quite a few cases in
> a harsh tone, you're behaving like a "bully". Please stop that.

One of the nice things about technical discussions is that it is
entirely possible for one particular party to be entirely wrong. In
this case, Brian is entirely wrong, and calling him on it is the
correct thing to do.

If you would prefer to see fewer emails from me, perhaps you should
start telling people who post the same incorrect claims that have
already been demonstrated to be false over and over again to stop it.
One of the unfortunate tendencies the Council has shown in the past is
to treat any unreplied-to objection as being legitimate and cause for
an issue to be postponed, even if that issue has already been addressed
earlier on.

--
Ciaran McCreesh
 
Old 02-26-2009, 10:07 AM
Petteri Räty
 
Default eapi function (Was: Collecting opinions about GLEP 55 and alternatives)

Ciaran McCreesh wrote:
> On Wed, 25 Feb 2009 23:43:44 -0100
> "Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org> wrote:
>> Ciaran McCreesh wrote:
>>> On Wed, 25 Feb 2009 16:02:46 -0800
>>> Brian Harring <ferringb@gmail.com> wrote:
>> < snip a few arguments>
>>
>> Ciaran and Brian,
>>
>> please respect Pettery's request and move your discussion to the
>> GLEP55 thread or to another thread, but leave it out of this one.
>
> This was moved to another thread, as a casual glance at the subject
> would have told you.
>

The In-Reply-To/References headers in your reply makes at least
Thunderbird put it to the same thread as my the original thread.
Probably similar logic exists in other email clients too. This means
that when using these clients this thread shows in the middle of the
opinion thread so please let's put all further replies elsewhere.

Regards,
Petteri
 

Thread Tools




All times are GMT. The time now is 03:14 AM.

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