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 06-11-2008, 02:56 AM
Brian Harring
 
Default extending existing EAPI semantics

Bit curious what folks opinions are re: conversion of eapi
requirements into a function, instead of a var. Essentially,
currently-

"""
#my ebuild.
EAPI=1
inherit blah
DEPEND=monkey

funcs_and_such(){:;}

"""

pros:
* simple, and was enough to get EAPI off the ground w/out massive
fighting (at least not WW3 level fighting)
* works fine for metadata key level changes, function changes, etc.
I'm aware folks have stated "if DEPENDS changes, it won't be able to
handle it"- they're frankly wrong, they're confusing that post
sourcing EAPI is checked, *then* if EAPI is supported the metadata is
handled, else the manager is signaled that an unknown eapi was
encountered (essentially). Continuing...

cons:
* EAPI var must be set effectively before any invocations occur.
* global scope invocations (inherit) must be eapi aware;
* future additions to global scope invocations (say elib) will result
in an error spat by bash ("elib wasn't found").
* bash specific (which personally is fine to me, an ebuild is bash).
* doesn't address versioning changes.

Converting it into

"""
#my ebuild.
eapi 1
inherit blah
DEPEND=monkey

funcs_and_such(){:;}

"""

with eapi effectively being

eapi() {
if [ "$1" == 1 ] || [ "$1" == 0 ];
return # we know this eapi, can handle it
fi
die "unsupported eapi $1"
}

pros:
* same benefits as preexisting var approach.
* via conversion to invocation instead of var setting (which is
untrappable), it's possible to bail the rest of the sourcing, thus
preventing any error msgs for unknown global invocations (elib fex).
* easy to shoehorn in for any profile.bashrc compliant manager
(portage/pkgcore); realize paludis is left out here (via it
intentionally being left out of PMS atm by ciaran), but
profile.bashrc *is* used by ebuild devs, thus it's a viable course (I
don't see profile.bashrc ever going away basically).

cons:
* must be the first invocation.
* bash specific (again, ebuild is bash, new format can do things
w/out having to worry about backwards compatibility).
* doesn't address versioning changes.


Basically, the proposal is an minor tweak of existing support- it has
the benefit of avoiding the filename complaints from folks and
addressing the usual "global scope invocation will breakzor in later
versions" complaint from paludis folk.

It doesn't particularly provide for people shoving new versioning
components in, but frankly that's fine due to the mess having
versioning rules bound to EAPI would entail.

After comments from folks, although if a responder is going to state
"filename is better!" skip it please, I already pointed out the diffs
(meaning bluntly, kindly skip repeating what has already been said).

Cheers
~harring
 
Old 06-11-2008, 03:20 AM
Ciaran McCreesh
 
Default extending existing EAPI semantics

On Tue, 10 Jun 2008 19:56:23 -0700
Brian Harring <ferringb@gmail.com> wrote:
> * easy to shoehorn in for any profile.bashrc compliant manager
> (portage/pkgcore); realize paludis is left out here (via it
> intentionally being left out of PMS atm by ciaran), but
> profile.bashrc *is* used by ebuild devs, thus it's a viable course (I
> don't see profile.bashrc ever going away basically).

If profile.bashrc is to be kept, it means massively reducing what can
be done in there.

> * doesn't address versioning changes.

Or indeed any change where the ebuild can't be visible to older package
managers without breaking them.

So basically it's not a solution at all.

--
Ciaran McCreesh
 

Thread Tools




All times are GMT. The time now is 09:21 PM.

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