Ciaran McCreesh wrote:
> On Sat, 16 May 2009 00:28:36 +0530
> Arun Raghavan wrote:
>> As I've stated a long time ago, I'm for this solution. My
>> understanding is that there are 2 objections to this:
>
> 3) It doesn't solve the problem. It doesn't allow things like version
> format extensions.
Duncan wrote:
> Tobias Klausmann posted
>> I was under the impression that it's illegal to change/set the EAPI
>> after using inherit.
>
> The short answer, based on my understanding of posts to this point, would
> be that it's illegal for Gentoo (in-tree, council decided), but not
> necessarily
On Sunday 17 May 2009 18:35:29 Ciaran McCreesh wrote:
> Please stop wasting everyone's time.
Yes, please do. Your replies are full of emotional arguments and ad hominem
attacks. If you are unable to keep to the technical aspects of a discussion
you should reconsider answering to every email (whi
On Sun, 17 May 2009 04:07:18 + (UTC)
Mark Bateman wrote:
> > On Sat, 16 May 2009 21:58:10 + (UTC)
> > Mark Bateman soon.com> wrote:
> > > "The current way of specifying the EAPI in ebuilds is flawed"
> > > That is not defining the problem, that is an opening statement.
> >
> > That is th
On Sunday 17 May 2009 08:29:31 Patrick Lauer wrote:
> I thought we had agreed that (1) with GLEP55 you have to source the ebuild
> anyway (whereas the other proposal allows to just parse it to get at the
> EAPI value) and (2) you can cache it sanely so that performance isn't the
> issue?
You don't
On Sunday 17 May 2009 09:40:14 Tiziano Müller wrote:
> Am Sonntag, den 17.05.2009, 01:50 +0100 schrieb Ciaran McCreesh:
> > On Sun, 17 May 2009 00:35:45 + (UTC)
> >
> > Duncan <1i5t5.dun...@cox.net> wrote:
> > > As for ciaranm's argument that you're restricting changes to the
> > > version stri
Am Sonntag, den 17.05.2009, 01:50 +0100 schrieb Ciaran McCreesh:
> On Sun, 17 May 2009 00:35:45 + (UTC)
> Duncan <1i5t5.dun...@cox.net> wrote:
> > As for ciaranm's argument that you're restricting changes to the
> > version string, say allowing -rc where _rc is now required, one-time
> > restri
On Sunday 17 May 2009 06:43:50 Richard Freeman wrote:
> Duncan wrote:
> > So I believe the cost to be quite reasonably managed, after all.
> > Benchmarks would of course be needed to demonstrate that, but I believe
> > it worth pursuing.
I thought we had agreed that (1) with GLEP55 you have to sour
Duncan wrote:
So I believe the cost to be quite reasonably managed, after all.
Benchmarks would of course be needed to demonstrate that, but I believe
it worth pursuing.
Agreed. Perhaps I'm just spoiled by RDBMS's at work or something, but
it seems like we're trying to squeeze every ounce
Ciaran McCreesh googlemail.com> writes:
>
> On Sat, 16 May 2009 21:58:10 + (UTC)
> Mark Bateman soon.com> wrote:
> > "The current way of specifying the EAPI in ebuilds is flawed"
> > That is not defining the problem, that is an opening statement.
>
> That is the problem.
No, that is a summ
Ciaran McCreesh posted
20090517015039.2fa04...@snowmobile, excerpted below, on Sun, 17 May 2009
01:50:39 +0100:
> On Sun, 17 May 2009 00:35:45 + (UTC) Duncan <1i5t5.dun...@cox.net>
> wrote:
>> As for ciaranm's argument that you're restricting changes to the
>> version string, say allowing -r
On Sun, 17 May 2009 00:35:45 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> As for ciaranm's argument that you're restricting changes to the
> version string, say allowing -rc where _rc is now required, one-time
> restriction of a year or two, yes. However, if the spec is crafted
> such that t
Nick Fortino posted 4a0f4ebc.5020...@gmail.com,
excerpted below, on Sat, 16 May 2009 16:39:40 -0700:
> line 5 shall contain the string EAPI="arg"
Given the bash expansion properties associated with double-quotes, that's
not really going to work as such. What if "arg" contains $var, where
$va
On Sat, 16 May 2009 21:58:10 + (UTC)
Mark Bateman wrote:
> "The current way of specifying the EAPI in ebuilds is flawed"
> That is not defining the problem, that is an opening statement.
That is the problem.
> "In order to get the EAPI the package manager needs to source the
> ebuild, which
Patrick Lauer gentoo.org> writes:
>
> For quite some time (over a year, actually) we've been discussing the
> mysterious and often misunderstood GLEP55.
> [http://www.gentoo.org/proj/en/glep/glep-0055.html]
>
> The proposed solution to a problem that is never refined, in short, is to add
> the
Oops, that was supposed to be sent to him directly. Sorry about that.
Denis.
On Sat, May 16, 2009 at 2:11 PM, Denis Dupeyron wrote:
> Joe !
>
> How are you doing ? I've been meaning to call you but I've been busy
> as hell due to the move. Do you want to have a beer or lunch sometime
> ?
>
> Den
Joe !
How are you doing ? I've been meaning to call you but I've been busy
as hell due to the move. Do you want to have a beer or lunch sometime
?
Denis.
David Leverton wrote:
> For comparson, another alternative that some people have suggested is putting
> it in a specially formatted comment. This avoids the issue I mentioned
> because bash doesn't try to parse those at all, so the only rules are those
> that specify what format the comment sho
On Saturday 16 May 2009 13:14:23 Duncan wrote:
> I mean, for the longest time, the main (among many) boosting claim seemed
> to be that the speed difference between in-file and in-filename made the
> former prohibitive in practice.
No, performance was never the point of GLEP 55. People like to ta
On Sat, 16 May 2009 11:34:14 -0400
Richard Freeman wrote:
> Ciaran McCreesh wrote:
> > Had we gone with any of the other proposals a year ago, we'd be
> > waiting a year every time a new change came along.
>
> Only if that change prevented obtaining EAPI from wherever it was
> placed.
...or if
Ciaran McCreesh wrote:
Had we gone with any of the other proposals a year ago, we'd be waiting
a year every time a new change came along.
Only if that change prevented obtaining EAPI from wherever it was
placed. If you want to make the rule "EAPI=foo appears at the start of
a new line at th
On Sat, 16 May 2009 11:15:58 -0400
Richard Freeman wrote:
> Ciaran McCreesh wrote:
> > You've missed the point. The point is, the EAPI process can't avoid
> > the "huge wait before we can use it" for certain types of change
> > that would be extremely useful. GLEP 55 fixes this limitation, and
> >
Ciaran McCreesh wrote:
You've missed the point. The point is, the EAPI process can't avoid the
"huge wait before we can use it" for certain types of change that
would be extremely useful. GLEP 55 fixes this limitation, and it's the
*only* thing that fixes this limitation.
Except that if we had
On Sat, 16 May 2009 15:50:39 +0100
Steven J Long wrote:
> Ciaran McCreesh wrote:
> > On Sat, 16 May 2009 11:27:10 +0200
> > Tobias Klausmann wrote:
> >> Change the spec, then.
> >
> > If we change the spec, we can't do anything with the change until
> > we're absolutely sure that everyone's upda
Ciaran McCreesh wrote:
> On Sat, 16 May 2009 11:27:10 +0200
> Tobias Klausmann wrote:
>> Change the spec, then.
>
> If we change the spec, we can't do anything with the change until we're
> absolutely sure that everyone's updated both their ebuilds and their
> package manager for it.
>
Isn't tha
On Sat, 16 May 2009 12:14:23 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> I mean, for the longest time, the main (among many) boosting claim
> seemed to be that the speed difference between in-file and
> in-filename made the former prohibitive in practice. Perhaps the
> benchmarks the counci
David Leverton posted
200905161059.53706.levert...@googlemail.com, excerpted below, on Sat, 16
May 2009 10:59:53 +0100:
> But the point isn't that we want to be able to do those things. The
> point is that if the EAPI is in the filename, it's blatantly obvious
> that it has to be static, but ad
Tobias Klausmann posted
20090516092710.ga3...@eric.schwarzvogel.de, excerpted below, on Sat, 16
May 2009 11:27:10 +0200:
> On Fri, 15 May 2009, Ciaran McCreesh wrote:
>> or:
>>
>> inherit versionator
>>
>> if version_is_at_least 2 ; then
>> EAPI="2"
>> else
>> EAP
Robert Bridge wrote:
> Patrick Lauer wrote:
>> On Thursday 14 May 2009 20:39:07 Ciaran McCreesh wrote:
>>> On Thu, 14 May 2009 20:06:51 +0200
>>>
>>> Patrick Lauer wrote:
Let EAPI be defined as (the part behind the = of) the first line of
the ebuild starting with EAPI=
>>> Uh, so horrib
On Fri, 15 May 2009 20:12:03 +0100
Steven J Long wrote:
> Robert R. Russell wrote:
>
> > If I understand the problem GLEP 55 is trying to solve correctly,
> > it stems from portage's assumption that an unknown EAPI is equal to
> > EAPI 0.
>
> No, portage will reject an ebuild with an unknown EAP
Robert R. Russell wrote:
> If I understand the problem GLEP 55 is trying to solve correctly, it stems
> from portage's assumption that an unknown EAPI is equal to EAPI 0.
No, portage will reject an ebuild with an unknown EAPI, as per the spec.
(This is important for shared overlays.) Search for:
31 matches
Mail list logo