В Втр, 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 h
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 sh
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
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
On Wed, 11 Jun 2008 04:15:35 -0700
Brian Harring <[EMAIL PROTECTED]> 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 _ you cannot change the
> ordering of an existing version component. Simple example you shou
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 pr
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 va
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 vers
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 a
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 eap
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
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
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
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 prev
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
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 "th
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 bei
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 ebuil
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
19 matches
Mail list logo
