Re: [gentoo-dev] extending existing EAPI semantics
В Втр, 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
Re: [gentoo-dev] extending existing EAPI semantics
On Wed, Jun 11, 2008 at 06:51:46AM +0100, Ciaran McCreesh wrote: On Wed, 11 Jun 2008 07:46:39 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Tue, 10 Jun 2008 22:33:41 -0700 Brian Harring [EMAIL PROTECTED] 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 pgpklKPIXKZ71.pgp Description: PGP signature
Re: [gentoo-dev] extending existing EAPI semantics
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
On Wed, Jun 11, 2008 at 12:58, Luca Barbato [EMAIL PROTECTED] 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
2008/6/11 Richard Brown [EMAIL PROTECTED]: On Wed, Jun 11, 2008 at 12:58, Luca Barbato [EMAIL PROTECTED] 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
[gentoo-dev] 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
pgpsalJ0dB2AH.pgp
Description: PGP signature
Re: [gentoo-dev] extending existing EAPI semantics
On Tue, 10 Jun 2008 19:56:23 -0700 Brian Harring [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
Re: [gentoo-dev] extending existing EAPI semantics
On Wed, Jun 11, 2008 at 04:20:04AM +0100, Ciaran McCreesh wrote: On Tue, 10 Jun 2008 19:56:23 -0700 Brian Harring [EMAIL PROTECTED] 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 pgp7ybFpcdLqq.pgp Description: PGP signature
Re: [gentoo-dev] extending existing EAPI semantics
On Tue, 10 Jun 2008 20:33:11 -0700 Brian Harring [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
Re: [gentoo-dev] extending existing EAPI semantics
On Wed, Jun 11, 2008 at 04:38:01AM +0100, Ciaran McCreesh wrote: On Tue, 10 Jun 2008 20:33:11 -0700 Brian Harring [EMAIL PROTECTED] 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 pgpQNmeUPmHge.pgp Description: PGP signature
Re: [gentoo-dev] extending existing EAPI semantics
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
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
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 pgpfpgcWqYDmG.pgp Description: PGP signature
Re: [gentoo-dev] extending existing EAPI semantics
On Tue, 10 Jun 2008 22:16:21 -0700 Brian Harring [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
Re: [gentoo-dev] extending existing EAPI semantics
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 [EMAIL PROTECTED] 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 pgpW4JMkxD1cz.pgp Description: PGP signature
Re: [gentoo-dev] extending existing EAPI semantics
On Tue, 10 Jun 2008 22:33:41 -0700 Brian Harring [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
Re: [gentoo-dev] extending existing EAPI semantics
Ciaran McCreesh wrote: On Tue, 10 Jun 2008 22:33:41 -0700 Brian Harring [EMAIL PROTECTED] 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
On Wed, 11 Jun 2008 07:46:39 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Tue, 10 Jun 2008 22:33:41 -0700 Brian Harring [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
