On Saturday 16 May 2009 20:17:14 Nick Fortino wrote:
> Ciaran McCreesh wrote:
> > On Sat, 16 May 2009 16:39:40 -0700
> >
> > Nick Fortino wrote:
> >> Given the above, it should be clear that any argument which states
> >> some future improvement to the ebuild format will be impossible based
> >>
Alistair Bush wrote:
Is it really necessary to convince the entire community for every GLEP?
I thought that the reason we have the council is so they can make
decisions. You know specialization of decision making. If the council
is going to expect anyone else, besides themselves, to understand
On Sun, 2009-05-17 at 07:40 -0400, Thomas Anderson wrote:
[...]
> The difference is that putting the EAPI in the filename has backwards
> compatibility because package managers not knowing about this change
> won't even look at the those ebuilds. Putting EAPI as the fifth line
> completely loses th
On Sun, May 17, 2009 at 12:35:43AM -0400, Richard Freeman wrote:
> Ravi Pinjala wrote:
>> Nick Fortino wrote:
>>> Such a transformation is possible, given the restrictions on arg, as
>>> well as ebuild format.
>> Isn't this a bit circular? The whole point of wanting to change the
>> extension is to
Ben de Groot wrote:
> Patrick Lauer wrote:
>> 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,
>
> This, in my
On Sat, 2009-05-16 at 20:21 +0100, Ciaran McCreesh wrote:
[...]
> Can't do that. The package manager has to barf on unrecognised .ebuild
> files.
I assume the reasons are the same as below.
> > If this is not viable, make an unrecognised version string cause the
> > same fallback as an unsupport
Ciaran McCreesh wrote:
The only way it'll be "in the next ten years" rather than "in the next
two years" is if Gentoo continues its current approach of making
changes require every single person to agree...
Frankly, I won't be at all surprised if this thread (in some form) is
still going on i
Ravi Pinjala wrote:
Nick Fortino wrote:
Such a transformation is possible, given the restrictions on arg, as
well as ebuild format.
Isn't this a bit circular? The whole point of wanting to change the
extension is to get rid of exactly these restrictions; if you assume the
restrictions, then th
Ciaran McCreesh wrote:
> On Sat, 16 May 2009 16:39:40 -0700
> Nick Fortino wrote:
>
>> Given the above, it should be clear that any argument which states
>> some future improvement to the ebuild format will be impossible based
>> upon making the wrong choice between proposal 1 and proposal 2 m
Nick Fortino wrote:
> Such a transformation is possible, given the restrictions on arg, as
> well as ebuild format.
Isn't this a bit circular? The whole point of wanting to change the
extension is to get rid of exactly these restrictions; if you assume the
restrictions, then the whole thing is kin
On Sat, 16 May 2009 16:39:40 -0700
Nick Fortino wrote:
> Given the above, it should be clear that any argument which states
> some future improvement to the ebuild format will be impossible based
> upon making the wrong choice between proposal 1 and proposal 2 must be
> invalid, as they have the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> On Sat, 16 May 2009 22:39:46 +0530
> Arun Raghavan wrote:
>
>> On Sat, 2009-05-16 at 17:59 +0100, Ciaran McCreesh wrote:
>>
Don't care. Let's fix the problems we have *now* using solutions
that we can agree upo
On Sun, 17 May 2009 00:42:58 +0530
Arun Raghavan wrote:
> On Sat, 2009-05-16 at 18:55 +0100, Ciaran McCreesh wrote:
> [...]
> > You have yet to provide an alternative for fixing the arbitrary and
> > pointless version format restrictions that are currently in place.
>
> Create an EAPI for the req
On Sat, 2009-05-16 at 18:55 +0100, Ciaran McCreesh wrote:
[...]
> You have yet to provide an alternative for fixing the arbitrary and
> pointless version format restrictions that are currently in place.
Create an EAPI for the required changes, fast track inclusion to a
stable portage.
If this is
On Sat, 16 May 2009 20:38:30 +0200
Robert Buchholz wrote:
> I like the fact that our versioning rules are a fixed subset of the
> sum of all our upstream's versioning rules. It provides a more
> consistent user experience.
>
> As a user, I know it's always "_rc" and never "-rc". Gentoo
> developer
On Saturday 16 May 2009, Ciaran McCreesh wrote:
> Have a look at every package using a MY_PV style thing. Group those
> into "upstream's doing something dumb" and "upstream's being sensible
> but our arbitrary restrictions on rules means we can't follow what
> they do".
I like the fact that our ve
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, May 16, 2009 at 07:14:00PM +0100, Ciaran McCreesh wrote:
> On Sat, 16 May 2009 13:10:07 -0500
> William Hubbs wrote:
> > Agreed. The way I have always usedEAPI is, you set it once at the top
> > of the EBUILD and you are done with it. As far
On Sat, 16 May 2009 13:10:07 -0500
William Hubbs wrote:
> Agreed. The way I have always usedEAPI is, you set it once at the top
> of the EBUILD and you are done with it. As far as I know, there is no
> reason to change EAPI once it is set, and eclasses shouldn't be
> changing it.
But eclasses h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, May 16, 2009 at 01:11:34PM +0200, Ben de Groot wrote:
> David Leverton wrote:
> > 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
On Sat, 16 May 2009 22:39:46 +0530
Arun Raghavan wrote:
> On Sat, 2009-05-16 at 17:59 +0100, Ciaran McCreesh wrote:
> > > Don't care. Let's fix the problems we have *now* using solutions
> > > that we can agree upon, rather than try to foist solutions that a
> > > reasonably large population of de
On Sat, 16 May 2009 19:13:21 +0200
Tobias Klausmann wrote:
> > Then you include those in your static list not using patterns that
> > deals with them.
>
> I'm unable to parse this sentence.
If you're writing a tool that deals with ebuilds, you should have a
list of EAPIs and their associated fi
Hi!
On Sat, 16 May 2009, Ciaran McCreesh wrote:
> Tobias Klausmann wrote:
> > > Why? What's the big deal with .ebuild-? or .eapi-?.eb instead
> > > of .ebuild?
> >
> > One that you illustrate yourself: what aboud .eapi-11.eb or
> > .ebuild-11?
>
> Then you include those in your static list not
On Sat, 2009-05-16 at 17:59 +0100, Ciaran McCreesh wrote:
[...]
> > Don't care. Let's fix the problems we have *now* using solutions that
> > we can agree upon, rather than try to foist solutions that a
> > reasonably large population of developers *don't* like (even after
> > extended debate) to s
On Sat, 16 May 2009 22:24:04 +0530
Arun Raghavan wrote:
> On Sat, 2009-05-16 at 17:47 +0100, Ciaran McCreesh wrote:
> > Ok, what are all the things requiring format-break changes that
> > we'll want in the next ten years? Please provide a complete list.
>
> Don't care. Let's fix the problems we h
On Sat, 16 May 2009 18:54:41 +0200
Tobias Klausmann wrote:
> > Why? What's the big deal with .ebuild-? or .eapi-?.eb instead
> > of .ebuild?
>
> One that you illustrate yourself: what aboud .eapi-11.eb or
> .ebuild-11?
Then you include those in your static list not using patterns that
deals with
Hi!
On Sat, 16 May 2009, Ciaran McCreesh wrote:
> On Sat, 16 May 2009 18:31:38 +0200
> Tobias Klausmann wrote:
> > On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > > > So we're not talking about .ebuild-2 for EAPI=2, .ebuild-3 for
> > > > EAPI=3 etc? That would just be silly and it was the first
On Sat, 2009-05-16 at 17:47 +0100, Ciaran McCreesh wrote:
>
> Ok, what are all the things requiring format-break changes that we'll
> want in the next ten years? Please provide a complete list.
Don't care. Let's fix the problems we have *now* using solutions that we
can agree upon, rather than tr
On Sat, 16 May 2009 22:14:30 +0530
Arun Raghavan wrote:
> On Sat, 2009-05-16 at 12:39 -0400, Thomas Anderson wrote:
> > For one, there's the restriction that all *-alpha/*-rc has to be
> > represented _rc/_alpha. I plan on doing more research into perhaps
> > lifting this restriction in a future E
On Sat, 2009-05-16 at 12:39 -0400, Thomas Anderson wrote:
[...]
> For one, there's the restriction that all *-alpha/*-rc has to be
> represented _rc/_alpha. I plan on doing more research into perhaps
> lifting this restriction in a future EAPI, but this would of course
> require glep 55's solution.
On Sat, 16 May 2009 22:05:08 +0530
Arun Raghavan wrote:
> So from all the debate that's going on, the current major issue seems
> to be being able to support '-scm' as per GLEP-54. What other
> restrictions in the version format are you referring to?
Have a look at every package using a MY_PV sty
On Sat, May 16, 2009 at 10:05:08PM +0530, Arun Raghavan wrote:
> On Sat, 2009-05-16 at 16:49 +0100, Ciaran McCreesh wrote:
> > On Sat, 16 May 2009 17:43:32 +0200
> > Tobias Klausmann wrote:
> > > > That doesn't let us do version format changes.
> > >
> > > Or are we talking about the *ebuild* ver
On Sat, 16 May 2009 18:31:38 +0200
Tobias Klausmann wrote:
> On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > > So we're not talking about .ebuild-2 for EAPI=2, .ebuild-3 for
> > > EAPI=3 etc? That would just be silly and it was the first idea I
> > > got when I saw the proposal.
> >
> > Yes, yes
On Sat, 2009-05-16 at 16:49 +0100, Ciaran McCreesh wrote:
> On Sat, 16 May 2009 17:43:32 +0200
> Tobias Klausmann wrote:
> > > That doesn't let us do version format changes.
> >
> > Or are we talking about the *ebuild* versions? I see that as
> > different matter. Plus: You could change the versi
Hi!
On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > So we're not talking about .ebuild-2 for EAPI=2, .ebuild-3 for
> > EAPI=3 etc? That would just be silly and it was the first idea I
> > got when I saw the proposal.
>
> Yes, yes we are. That's just one change, from a static string to a
> patter
On Sat, 16 May 2009 18:15:58 +0200
Tobias Klausmann wrote:
> On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > Tobias Klausmann wrote:
> > > > Yes, those. The current rules include some pointless arbitrary
> > > > restrictions that are only there for historical reasons and that
> > > > mean people
Hi!
On Sat, 16 May 2009, Ciaran McCreesh wrote:
> Tobias Klausmann wrote:
> > > Yes, those. The current rules include some pointless arbitrary
> > > restrictions that are only there for historical reasons and that
> > > mean people have to mess with convoluted MY_PV things.
> >
> > Still: a san
On Sat, 16 May 2009 17:55:01 +0200
Tobias Klausmann wrote:
> > Yes, those. The current rules include some pointless arbitrary
> > restrictions that are only there for historical reasons and that
> > mean people have to mess with convoluted MY_PV things.
>
> Still: a sane spec for those plus a san
Hi!
On Sat, 16 May 2009, Ciaran McCreesh wrote:
> On Sat, 16 May 2009 17:43:32 +0200
> Tobias Klausmann wrote:
> > > That doesn't let us do version format changes.
> >
> > Or are we talking about the *ebuild* versions? I see that as
> > different matter. Plus: You could change the version form
On Sat, 16 May 2009 17:43:32 +0200
Tobias Klausmann wrote:
> > That doesn't let us do version format changes.
>
> Or are we talking about the *ebuild* versions? I see that as
> different matter. Plus: You could change the version format with
> the changed extension. I sure do hope there are no pl
Hi!
On Sat, 16 May 2009, Ciaran McCreesh wrote:
> On Sat, 16 May 2009 17:32:24 +0200
> Tobias Klausmann wrote:
> > On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > > On Sat, 16 May 2009 11:27:10 +0200
> > > Tobias Klausmann wrote:
> > > > Change the spec, then.
> > >
> > > If we change the spec
On Sat, 16 May 2009 17:32:24 +0200
Tobias Klausmann wrote:
> On Sat, 16 May 2009, 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
Hi!
On Sat, 16 May 2009, 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
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.
> Actually, I personally would prefer taking it
David Leverton wrote:
> 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 adding strange and unintuitive restrictions on which shell
> constructs can be used is, well, strang
On Saturday 16 May 2009 10:27:51 Marijn Schouten (hkBst) wrote:
> How is it possible to do these things encoded in the filename?
For the export example, it's just a matter of using a different bash syntax
from what the magic regex expects, which is completely irrelevant if it goes
in the filenam
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> On Fri, 15 May 2009 14:43:29 -0500
> William Hubbs wrote:
>> On Thu, May 14, 2009 at 10:53:37PM +0100, Ciaran McCreesh wrote:
>>> It can't, because it doesn't know the EAPI until it's sourced the
>>> thing using bash. Using th
Hi!
On Fri, 15 May 2009, Ciaran McCreesh wrote:
> > eval `grep '^EAPI=' ebuildfile | head -n 1`
> >
> > will set EAPI in the current scope to EAPI in the ebuild, without
> > sourcing it, unless the issue with something like this would be its
> > use of grep and head, but these are both in the sy
On Fri, 15 May 2009 14:43:29 -0500
William Hubbs wrote:
> On Thu, May 14, 2009 at 10:53:37PM +0100, Ciaran McCreesh wrote:
> > It can't, because it doesn't know the EAPI until it's sourced the
> > thing using bash. Using things like += in global scope will break
> > older bash versions to the poin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, May 14, 2009 at 10:53:37PM +0100, Ciaran McCreesh wrote:
> It can't, because it doesn't know the EAPI until it's sourced the thing
> using bash. Using things like += in global scope will break older bash
> versions to the point that they can't
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.
That's the big one, not the other t
On Fri, 2009-05-15 at 00:44 +0200, Patrick Lauer wrote:
[...]
> So if you were a lazy Unix coder you'd just restrict the current rules a bit
> so that there's only one line starting with EAPI= allowed (or maybe you just
> take the first or last one, but that's annoying) and if no such line matche
On Fri, 15 May 2009 11:16:11 -0500
"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. Could that assumption be changed to an unknown EAPI is equal to
> the latest supported E
On Friday 15 May 2009 05:44:47 Richard Freeman wrote:
> 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 horribly utterly and obviou
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 horribly utterly and obviously wrong.
inherit foo
EAPI=4
where foo is both a global and a non-glob
On Friday 15 May 2009 02:42:33 George Prowse wrote:
> Having countered those four points I guess you agree with the other five
> then. Over 50% success rate (by your definition) is hardly being
> ignorant or trolling
In that case we can assume that Patrick agrees with all my counterpoints,
since
Ciaran McCreesh wrote:
On Thu, 14 May 2009 20:06:51 +0200
Patrick Lauer wrote:
"You need to know the EAPI to parse the ebuild to find the EAPI"
Obviously that's not true, because somehow we manage at the moment.
And if one does a small restriction (which doesn't restrict current
behaviour becau
On Thursday 14 May 2009 23:53:37 Ciaran McCreesh wrote:
> On Thu, 14 May 2009 16:49:09 -0500
>
> William Hubbs wrote:
> > The second solution seems to be the better one because it does not go
> > against standards. For example, we see extentions like .c, .py and
> > .pl, instead of .c-43, .py-25
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 14 May 2009 16:49:09 -0500
William Hubbs wrote:
> The second solution seems to be the better one because it does not go
> against standards. For example, we see extentions like .c, .py and
> .pl, instead of .c-43, .py-25 and .pl-58. There ar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I realize that I'm asking this very late in the discussion, so please
bear with me if it has been hashed before.
On Thu, May 14, 2009 at 11:16:23PM +0200, Peter Alfredsen wrote:
> We need a mechanism to be able to use newer bash-features in ebuil
On Thu, 14 May 2009 22:03:22 +0200
Ben de Groot wrote:
> I concur that speaking for myself, I don't understand the issue. And
> it looks like many others don't either. So if anyone wants to promote
> this GLEP, their job is clear: make people understand what the issue
> is here, and convince them
Patrick Lauer wrote:
> 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,
This, in my opinion, is the crux of the m
On Thu, 14 May 2009 21:24:14 +0200
Patrick Lauer wrote:
> > "so with glep55 caching it is actually slower!"
> >
> > There's no possible way that can make sense. Whatever he's claiming
> > by that is obviously nonsense.
>
> Ah. I was not precise enough.
>
> Let me rephrase it in less ambiguous te
On Thu, 14 May 2009 14:15:28 -0500
Jeremy Olexa wrote:
> On Thu, May 14, 2009 at 2:06 PM, David Leverton
> wrote:
> > yourself, "shell-like". "printf -v EAPI 1" is perfectly valid
> > shell (at least if we decide to allow bash 3.1 features), and has
> > the same effect
>
> To stir things up:
>
On Thursday 14 May 2009 21:20:18 Ciaran McCreesh wrote:
> On Thu, 14 May 2009 13:17:24 -0600
>
> RB wrote:
> > On Thu, May 14, 2009 at 13:11, Ciaran McCreesh
> >
> > wrote:
> > > Please explain why you claimed GLEP 55 makes things slower. Until
> > > you answer that, it's hard to take you for any
On Thu, 14 May 2009 13:17:24 -0600
RB wrote:
> On Thu, May 14, 2009 at 13:11, Ciaran McCreesh
> wrote:
> > Please explain why you claimed GLEP 55 makes things slower. Until
> > you answer that, it's hard to take you for anything other than a
> > troll.
>
> Hell, I'll explain. Read paragraph 8 a
On Thu, 14 May 2009 21:09:58 +0200
Tomáš Chvátal wrote:
> Dne čtvrtek 14 Květen 2009 20:39:07 Ciaran McCreesh napsal(a):
> > Where on earth are you getting the idea that GLEP 55 makes things
> > slower? The only difference to the code with GLEP 55 is in checking
> > file extensions against a sligh
On Thu, May 14, 2009 at 13:11, Ciaran McCreesh
wrote:
> Please explain why you claimed GLEP 55 makes things slower. Until you
> answer that, it's hard to take you for anything other than a troll.
Hell, I'll explain. Read paragraph 8 again. Slowly. Read it a
second time, since you obviously did
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 horribly utterly and obviously wrong.
inherit fo
On Thu, May 14, 2009 at 2:06 PM, David Leverton
wrote:
> yourself, "shell-like". "printf -v EAPI 1" is perfectly valid shell (at
> least if we decide to allow bash 3.1 features), and has the same effect
To stir things up:
Who decides this? There are more and more bash-3.1 features in the
tree a
On Thu, 14 May 2009 21:05:52 +0200
Patrick Lauer wrote:
> > Where on earth are you getting the idea that GLEP 55 makes things
> > slower? The only difference to the code with GLEP 55 is in checking
> > file extensions against a slightly larger set of strings, which is
> > nowhere near a measurable
Dne čtvrtek 14 Květen 2009 20:39:07 Ciaran McCreesh napsal(a):
> Where on earth are you getting the idea that GLEP 55 makes things
> slower? The only difference to the code with GLEP 55 is in checking
> file extensions against a slightly larger set of strings, which is
> nowhere near a measurable i
On Thursday 14 May 2009 19:06:51 Patrick Lauer wrote:
> 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]
We agree on the latter adjective, if nothing else.
> The proposed soluti
On Thursday 14 May 2009 20:39:07 Ciaran McCreesh wrote:
> On Thu, 14 May 2009 20:06:51 +0200
>
> Patrick Lauer wrote:
> > "You need to know the EAPI to parse the ebuild to find the EAPI"
> > Obviously that's not true, because somehow we manage at the moment.
> > And if one does a small restriction
On Thu, 14 May 2009 20:06:51 +0200
Patrick Lauer wrote:
> "You need to know the EAPI to parse the ebuild to find the EAPI"
> Obviously that's not true, because somehow we manage at the moment.
> And if one does a small restriction (which doesn't restrict current
> behaviour because all in-tree ebu
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 EAPI into the ebuild filename "to make things easi
75 matches
Mail list logo
