[gentoo-dev] extending existing EAPI semantics

[gentoo-dev] extending existing EAPI semantics

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2809 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] extending existing EAPI semantics

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] extending existing EAPI semantics

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1285 bytes --]

On Wed, Jun 11, 2008 at 04:20:04AM +0100, Ciaran McCreesh wrote:
> 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.

Restraint in use of profile.bashrc is a per community QA measure, not 
a format restriction- think through the other "this is better for QA" 
things I've suggested PMS wise, you've responded in the same manner.


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

Name a scenario.

Note, if the scenario is "pm doesn't support eapi function, and 
doesn't support profile.bashrc", skip it, you're repeating what I 
already laid out (which results in visible bash complaints, but the 
manager still labeling the eapi inoperable).
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] extending existing EAPI semantics

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

On Tue, 10 Jun 2008 20:33:11 -0700
Brian Harring <ferringb@gmail.com> wrote:
> > If profile.bashrc is to be kept, it means massively reducing what
> > can be done in there.
> 
> Restraint in use of profile.bashrc is a per community QA measure, not 
> a format restriction- think through the other "this is better for QA" 
> things I've suggested PMS wise, you've responded in the same manner.

Except that if profile.bashrc can tinker with package manager
internals, it has to be done in such a way that it works with all
package managers. So it has to be either Portage-specific or extremely
constrained.

> > > * 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.
> 
> Name a scenario.

You already named one, and tried to gloss it over as not being the
complete showstopper that it is.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] extending existing EAPI semantics

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2286 bytes --]

On Wed, Jun 11, 2008 at 04:38:01AM +0100, Ciaran McCreesh wrote:
> On Tue, 10 Jun 2008 20:33:11 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> > > > * 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.
> > 
> > Name a scenario.
> 
> You already named one, and tried to gloss it over as not being the
> complete showstopper that it is.

Not exactly a show stopper; unknown versions are by and large 
ignored due to paludis devs forcing it upon others.  Ironic, that one.

You're also ignoring is that unlike the .ebuild-$EAPI approach, 
this minor refinement leaves open options for replacement, and that 
this option actually is likely far more agreeable then the filename 
approach you've been trying to force since EAPI's inception (which 
thus far hasn't taken hold despite positively massive noise from you).

One thing I'll note is that the .ebuild-$EAPI approach isn't the end 
all fix to versioning extensions that y'all represent it as.  
Essentially, what .ebuild-$EAPI allows is additions to version 
comparison rules, no subtractions.  Each new $EAPI *must* be a 
superset of previous $EAPIs.

An example would be removal of float comparison rules; for <=eapi-1, 
.006 < .6;  Now if eapi-2 stated .006 == .6, that literally means that 
the PM would have to maintain versioning rules per eapi level, meaning 
that for an eapi1 ebuild, what it would match would differ from eapi2.  
Aside from that being a cluster-fuck in the implementation, it's a 
cluster-fuck for the dev trying to visualize what the manager is 
actually up to.

Personally, that's a pretty nasty unstated gotcha.  .ebuild-$EAPI 
isn't the end all essentially, it has flaws just the same as other 
solutions.

Marius/genone has advocated it in the past, and frankly I tend to 
agree at this point- versioning rules are a repo level property by and 
large, and the appropriate place to control that is at the repo level.

So... someone other then ciaran have a comment?  We already know 
ciarans views (hard not to when he has 2x greater posting ratio then 
any other person)...

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] extending existing EAPI semantics

[Mike Kelly]

Brian Harring wrote:
> One thing I'll note is that the .ebuild-$EAPI approach isn't the end 
> all fix to versioning extensions that y'all represent it as.  
> Essentially, what .ebuild-$EAPI allows is additions to version 
> comparison rules, no subtractions.  Each new $EAPI *must* be a 
> superset of previous $EAPIs.

Uhh... no. Just like how older package managers which don't understand 
how to read the EAPI from a filename suffix would basically ignore the 
new ebuilds, any package manager that can, but doesn't recognize the 
eapi of the new one, will just ignore it. It won't ever try to figure 
out its version or anything, it'll just do nothing.

Also, there is absolutely no reason for all future EAPIs to be a 
superset of old eapis. While paludis (and presumably pkgcore and 
portage, I'm not as familiar with their code) has implemented EAPI=1 as 
a few additions to EAPI=0, there is no reason that gentoo might not 
decide to have EAPI=9000 some day, complete with artificial intelligence 
that completely obsoletes USE flags, or some such thing (it's late, I 
know the analogy sucks).


-- 
Mike Kelly
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] extending existing EAPI semantics

[Luca Barbato]

Mike Kelly wrote:
> Brian Harring wrote:
>> One thing I'll note is that the .ebuild-$EAPI approach isn't the end 
>> all fix to versioning extensions that y'all represent it as.  
>> Essentially, what .ebuild-$EAPI allows is additions to version 
>> comparison rules, no subtractions.  Each new $EAPI *must* be a 
>> superset of previous $EAPIs.
> 
> Uhh... no. Just like how older package managers which don't understand 
> how to read the EAPI from a filename suffix would basically ignore the 
> new ebuilds, any package manager that can, but doesn't recognize the 
> eapi of the new one, will just ignore it. It won't ever try to figure 
> out its version or anything, it'll just do nothing.
> 
> Also, there is absolutely no reason for all future EAPIs to be a 
> superset of old eapis. While paludis (and presumably pkgcore and 
> portage, I'm not as familiar with their code) has implemented EAPI=1 as 
> a few additions to EAPI=0, there is no reason that gentoo might not 
> decide to have EAPI=9000 some day, complete with artificial intelligence 
> that completely obsoletes USE flags, or some such thing (it's late, I 
> know the analogy sucks).
> 

Assuming we won't move from flat file to db

lu - thinking of a darker future.


-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] extending existing EAPI semantics

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 3492 bytes --]

You actually pretty much completely misinterpreted what I was saying, 
so inserting the example back into the email and trying again...

On Wed, Jun 11, 2008 at 12:25:55AM -0400, Mike Kelly wrote:
> Brian Harring wrote:
> >One thing I'll note is that the .ebuild-$EAPI approach isn't the end 
> >all fix to versioning extensions that y'all represent it as.  
> >Essentially, what .ebuild-$EAPI allows is additions to version 
> >comparison rules, no subtractions.  Each new $EAPI *must* be a 
> >superset of previous $EAPIs.
>
> >An example would be removal of float comparison rules; for 
> ><=eapi-1, .006 < .6;  Now if eapi-2 stated .006 == .6, that 
> >literally means that the PM would have to maintain versioning rules 
> >per eapi level, meaning that for an eapi1 ebuild, what it would 
> >match would differ from eapi2. Aside from that being a 
> >cluster-fuck in the implementation, it's a cluster-fuck for the dev 
> >trying to visualize what the manager is actually up to.
>
> Uhh... no. Just like how older package managers which don't understand 
> how to read the EAPI from a filename suffix would basically ignore the 
> new ebuilds, any package manager that can, but doesn't recognize the 
> eapi of the new one, will just ignore it. It won't ever try to figure 
> out its version or anything, it'll just do nothing.

Here's the scenario:

1) EAPI1 defines foo-0.006 < foo-0.6.
2) EAPI2 redefine it so that foo-0.006 == foo-0.6
3) pkg 'a' has one version- '0.006'
4) pkg b-1, EAPI=1; DEPEND='<=a-0.006'
5) pkg c-1, EAPI=2; DEPEND='>=a-0.6'

Now, via EAPI1 definition, b-1 *must* match a-0.006; via EAPI2 
definition, b-2 *must* match a-0.006 also.  The only way the manager 
can properly support this request is via getting the EAPI from the pkg 
that specified that request.

Literally, the ordering of matches would have to vary dependant upon 
the eapi of the pkg.  This is a serious cluster fuck for any 
implementation, and it's a pretty nice gotcha for ebuild developers.

The sane alternative here is that each successive EAPI release, 
specifically the versioning rules, must be a superset of existing.  
Via that you can induce a total ordering that works regardless of the 
EAPI level of the generating pkg.

A scenario that is far more entertaining is how the manager is 
supposed to handle the following:

1) EAPI2 defines 1.0-scm > 1.0
2) pkg 'a' has one visible version; 1.0-scm
3) pkg b-1 EAPI=1, DEPEND='<=a-1'
4) pkg c-1 EAPI=2, DEPEND='a'

What is the correct result here?  Since b-1's versioning rules don't 
know a damn thing about -scm, should it even be possible for it to use 
that version?  The only valid solution here (since EAPI1 does not 
know, nor specify the ordering of -scm) is to bail.

If you're maintaing a total ordering (each EAPI a superset of the 
last for versioning rules), you *could* retroactively decide on that 
case.

Either way, point is that .ebuild-$EAPI doesn't magically solve 
versioning changes.  It hides away user visibility of it, but doesn't 
solve the real issue.


> Also, there is absolutely no reason for all future EAPIs to be a 
> superset of old eapis.

.ebuild-$EAPI-n requires all *versioning rules* to be a superset of 
$EAPI=(n-1); if in doubt, re-read my example above.

Non versioning rules of $EAPI, no, no requirement to be supersets of 
proceeding- but versioning under .ebuild-$EAPI, yes, it's required.

Cheers,
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] extending existing EAPI semantics

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 531 bytes --]

On Tue, 10 Jun 2008 22:16:21 -0700
Brian Harring <ferringb@gmail.com> wrote:
> > Also, there is absolutely no reason for all future EAPIs to be a 
> > superset of old eapis.
> 
> .ebuild-$EAPI-n requires all *versioning rules* to be a superset of 
> $EAPI=(n-1); if in doubt, re-read my example above.

No it doesn't. It requires that versions be mappable to a single,
enumerable master version format. Big difference. You could quite
happily add -scm and remove _p in future EAPIs, for example.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] extending existing EAPI semantics

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

Kindly respond to the rest of the email first of all...

On Wed, Jun 11, 2008 at 06:22:31AM +0100, Ciaran McCreesh wrote:
> On Tue, 10 Jun 2008 22:16:21 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> > > Also, there is absolutely no reason for all future EAPIs to be a 
> > > superset of old eapis.
> > 
> > .ebuild-$EAPI-n requires all *versioning rules* to be a superset of 
> > $EAPI=(n-1); if in doubt, re-read my example above.
> 
> No it doesn't. It requires that versions be mappable to a single,
> enumerable master version format. Big difference. You could quite
> happily add -scm and remove _p in future EAPIs, for example.

Lay out how .006/.6 would work properly *per* eapi.  As I clarified in 
my last email, the master would vary dependant on the eapi- which 
isn't valid unless you're retroactively overriding the versioning 
rules of an eapi.
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] extending existing EAPI semantics

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 435 bytes --]

On Tue, 10 Jun 2008 22:33:41 -0700
Brian Harring <ferringb@gmail.com> wrote:
> Lay out how .006/.6 would work properly *per* eapi.  As I clarified
> in my last email, the master would vary dependant on the eapi- which 
> isn't valid unless you're retroactively overriding the versioning 
> rules of an eapi.

"Must be a superset" being wrong does not mean "entirely arbitrary
changes are OK" is right.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] extending existing EAPI semantics

[Luca Barbato]

Ciaran McCreesh wrote:
> On Tue, 10 Jun 2008 22:33:41 -0700
> Brian Harring <ferringb@gmail.com> wrote:
>> Lay out how .006/.6 would work properly *per* eapi.  As I clarified
>> in my last email, the master would vary dependant on the eapi- which 
>> isn't valid unless you're retroactively overriding the versioning 
>> rules of an eapi.
> 
> "Must be a superset" being wrong does not mean "entirely arbitrary
> changes are OK" is right.

You have actual usecases (eventually not thin air), which is your 
counterproposal that works for them?

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] extending existing EAPI semantics

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 805 bytes --]

On Wed, 11 Jun 2008 07:46:39 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > On Tue, 10 Jun 2008 22:33:41 -0700
> > Brian Harring <ferringb@gmail.com> wrote:
> >> Lay out how .006/.6 would work properly *per* eapi.  As I clarified
> >> in my last email, the master would vary dependant on the eapi-
> >> which isn't valid unless you're retroactively overriding the
> >> versioning rules of an eapi.
> > 
> > "Must be a superset" being wrong does not mean "entirely arbitrary
> > changes are OK" is right.
> 
> You have actual usecases (eventually not thin air), which is your 
> counterproposal that works for them?

Care to rephrase that in English? I'm not proposing anything, so I'm at
a loss as to what you're going on about here.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] extending existing EAPI semantics

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]

On Wed, Jun 11, 2008 at 06:51:46AM +0100, Ciaran McCreesh wrote:
> On Wed, 11 Jun 2008 07:46:39 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
> > Ciaran McCreesh wrote:
> > > On Tue, 10 Jun 2008 22:33:41 -0700
> > > Brian Harring <ferringb@gmail.com> wrote:
> > >> Lay out how .006/.6 would work properly *per* eapi.  As I clarified
> > >> in my last email, the master would vary dependant on the eapi-
> > >> which isn't valid unless you're retroactively overriding the
> > >> versioning rules of an eapi.
> > > 
> > > "Must be a superset" being wrong does not mean "entirely arbitrary
> > > changes are OK" is right.
> > 
> > You have actual usecases (eventually not thin air), which is your 
> > counterproposal that works for them?
> 
> Care to rephrase that in English? I'm not proposing anything, so I'm at
> a loss as to what you're going on about here.

Being that you can't understand the problem you're commenting on, I'll 
explain it for you.

While you can remove _p1, or _<random_suffix> you cannot change the 
ordering of an existing version component.  Simple example you should 
grok, changing of 1_p1 such that it's <1.0 is not valid.

As I've indicated repeatedly in this thread, and y'all have missed, 
you cannot change the semantics of the ordering.  Sure, you could
remove a version component from usage- that said, you cannot change 
it's ordering.

Further, you cannot change the ordering of an existing version- if 
you can't understand why shifting 0.006 to equivalent to 0.6, then 
frankly, this discussion need not continue.

Cheers.
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] extending existing EAPI semantics

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1587 bytes --]

On Wed, 11 Jun 2008 04:15:35 -0700
Brian Harring <ferringb@gmail.com> wrote:
> Being that you can't understand the problem you're commenting on,
> I'll explain it for you.
> 
> While you can remove _p1, or _<random_suffix> you cannot change the 
> ordering of an existing version component.  Simple example you should 
> grok, changing of 1_p1 such that it's <1.0 is not valid.
> 
> As I've indicated repeatedly in this thread, and y'all have missed, 
> you cannot change the semantics of the ordering.  Sure, you could
> remove a version component from usage- that said, you cannot change 
> it's ordering.

Except that isn't what you said. What you said is:

> One thing I'll note is that the .ebuild-$EAPI approach isn't the end 
> all fix to versioning extensions that y'all represent it as.  
> Essentially, what .ebuild-$EAPI allows is additions to version 
> comparison rules, no subtractions.  Each new $EAPI *must* be a 
> superset of previous $EAPIs.

Which is obviously untrue. Here's a perfectly consistent, perfectly
implementable (but probably not desirable) rule for versions for a
future EAPI that is not a strict subset, nor is it additions:

"Any package using EAPI 2 may not use any version component that uses
leading zeros. Any package manager supporting EAPI 2 must support scm."

> Further, you cannot change the ordering of an existing version- if 
> you can't understand why shifting 0.006 to equivalent to 0.6, then 
> frankly, this discussion need not continue.

http://en.wikipedia.org/wiki/Straw_man

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] extending existing EAPI semantics

[Luca Barbato]

Ciaran McCreesh wrote:
> 
> http://en.wikipedia.org/wiki/Straw_man
> 

http://en.wikipedia.org/wiki/Quote_mining

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] extending existing EAPI semantics

[Richard Brown]

On Wed, Jun 11, 2008 at 12:58, Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
>>
>> http://en.wikipedia.org/wiki/Straw_man
>>
>
> http://en.wikipedia.org/wiki/Quote_mining

http://en.wikipedia.org/wiki/Idiot

-- 
Richard Brown
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] extending existing EAPI semantics

[Nirbheek Chauhan]

2008/6/11 Richard Brown <rbrown@exherbo.org>:
> On Wed, Jun 11, 2008 at 12:58, Luca Barbato <lu_zero@gentoo.org> wrote:
>> Ciaran McCreesh wrote:
>>>
>>> http://en.wikipedia.org/wiki/Straw_man
>>>
>>
>> http://en.wikipedia.org/wiki/Quote_mining
>
> http://en.wikipedia.org/wiki/Idiot

The following should effectively end this string of Wikipedia references:

http://en.wikipedia.org/wiki/Flaming_(Internet)
http://en.wikipedia.org/wiki/Personal_attacks

Thank you, and have a nice day|night.

-- 
~Nirbheek Chauhan
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] extending existing EAPI semantics

[Peter Volkov]

В Втр, 10/06/2008 в 21:10 -0700, Brian Harring пишет:
> So... someone other then ciaran have a comment?

>From ebuild developer point of view there is no difference if eapi is a
variable of a function call. If changing eapi to a function call makes
sourcing of ebuilds more sane, then it's good to have such change.

-- 
Peter.

-- 
gentoo-dev@lists.gentoo.org mailing list