On Mon, 18 May 2009 01:30:26 +0200
Ulrich Mueller wrote:
> > On Mon, 18 May 2009, Ciaran McCreesh wrote:
> >> How? Both "limit-1_14" and "erlang-12B5" are valid package names,
> >> so how do you determine where PN ends and where PV starts?
>
> > By the time the things we need to get this done
> On Mon, 18 May 2009, Ciaran McCreesh wrote:
>> How? Both "limit-1_14" and "erlang-12B5" are valid package names,
>> so how do you determine where PN ends and where PV starts?
> By the time the things we need to get this done end up being
> accepted, we'll probably be using ranged deps, so i
On Mon, 18 May 2009 01:11:45 +0200
Ulrich Mueller wrote:
> > On Sun, 17 May 2009, Ciaran McCreesh wrote:
> >> 1_14 -> 1.14(app-emacs/limit)
> >> 12B5 -> 12.2.5 (dev-lang/erlang)
>
> > These we should handle.
>
> How? Both "limit-1_14" and "erlang-12B5" are va
> On Sun, 17 May 2009, Ciaran McCreesh wrote:
>> 1_14 -> 1.14(app-emacs/limit)
>> 12B5 -> 12.2.5 (dev-lang/erlang)
> These we should handle.
How? Both "limit-1_14" and "erlang-12B5" are valid package names,
so how do you determine where PN ends and where PV s
On Mon, 18 May 2009 00:54:04 +0200
Ulrich Mueller wrote:
> > Upstreams don't standardise either way on - vs _, so there's no
> > reason Gentoo should.
>
> Upstreams use all sorts of strange versioning schemes. Here is a small
> collection:
And we can handle a lot more of them sensibly than we cu
> On Sun, 17 May 2009, Ciaran McCreesh wrote:
> Upstreams don't standardise either way on - vs _, so there's no
> reason Gentoo should.
Upstreams use all sorts of strange versioning schemes. Here is a small
collection:
1_14 -> 1.14(app-emacs/limit)
1.0pre4-> 1
2009/5/17 Ben de Groot :
> Ciaran McCreesh wrote:
>> On Sun, 17 May 2009 23:17:57 +0200
>> Ben de Groot wrote:
>>> 2. "Add new global scope functions in any sane way"
>>> This is a valid use case, as seen by the eapi-2 update. But the way
>>> this is currently handled by portage (advising to upgra
On Mon, 18 May 2009 00:08:05 +0200
Ben de Groot wrote:
> > There are already horrible hacks in the tree to get per-package
> > 'eclasses'. That's a clear sign there's something lacking.
>
> I haven't come across any horrible hacks, that I'm aware of, but of
> course my interest is only in certain
Ciaran McCreesh wrote:
> On Sun, 17 May 2009 23:17:57 +0200
> Ben de Groot wrote:
>> 1. "Incompatible change of inherit (e.g. make it look in the package
>> dir too)"
>> A case would need to be made, in my opinion, as to why we would wish
>> to allow this in the first place. The current inherit be
Ciaran McCreesh wrote:
>> 3. "Extend versioning rules in an EAPI - for example, addition of the
>> scm suffix - GLEP54 [1] or allowing more sensible version formats like
>> 1-rc1, 1-alpha etc. to match upstream more closely."
>> Apart from GLEP54, I believe our versioning scheme works reasonably
>>
On Sun, 17 May 2009 23:17:57 +0200
Ben de Groot wrote:
> 1. "Incompatible change of inherit (e.g. make it look in the package
> dir too)"
> A case would need to be made, in my opinion, as to why we would wish
> to allow this in the first place. The current inherit behavior with
> eclasses in a cen
Let me first say that I think this revision is much improved, and makes
it clearer what we are talking about.
As to the stated problem(s):
1. "Incompatible change of inherit (e.g. make it look in the package dir
too)"
A case would need to be made, in my opinion, as to why we would wish to
allow t
On Sun, 17 May 2009 21:57:40 +0200
Thomas de Grenier de Latour wrote:
> On 2009/05/17, Ciaran McCreesh wrote:
> > You don't define it quite like that. You define it by mapping EAPI X
> > _p onto super-EAPI _p0, and EAPI Y _p onto super_EAPI _pINFINITY.
> > That way the ordering's well defined.
>
On 2009/05/17, Ciaran McCreesh wrote:
> > Let's take a very simple
> > example:
> > - eapi X says "_p is equal to _p0"
> > - eapi Y says "_p is greater than any _pN"
> > --> of "foo-1_p1 with EAPI=X" and "foo-1_p with EAPI=Y", what is
> > the "best" version?
>
> You don't define it quit
2009/5/17 Robert Buchholz :
> On Sunday 17 May 2009, Piotr Jaroszyński wrote:
>> Hello,
>>
>> I have just updated GLEP 55 [1], hopefully making it a bit clearer.
>>
>> Just FYI, my order of preference of solutions is:
>>
>> 1. EAPI-suffixed ebuilds (obviously)
>> 2. EAPI in the filename with one-ti
2009-05-17 20:57:25 Robert Buchholz napisał(a):
> On Sunday 17 May 2009, Piotr Jaroszyński wrote:
> > Hello,
> >
> > I have just updated GLEP 55 [1], hopefully making it a bit clearer.
> >
> > Just FYI, my order of preference of solutions is:
> >
> > 1. EAPI-suffixed ebuilds (obviously)
> > 2. EAPI
On Sunday 17 May 2009, Piotr Jaroszyński wrote:
> Hello,
>
> I have just updated GLEP 55 [1], hopefully making it a bit clearer.
>
> Just FYI, my order of preference of solutions is:
>
> 1. EAPI-suffixed ebuilds (obviously)
> 2. EAPI in the filename with one-time extension change
> 3. Easily fetcha
On Sun, 17 May 2009 22:54:38 +0530
Nirbheek Chauhan wrote:
> On Sun, May 17, 2009 at 9:36 PM, Peter Alfredsen
> wrote:
> > On Sun, 17 May 2009 17:56:06 +0200
> > Piotr Jaroszyński wrote:
> >
> >> I know gentoo has other problems too, but it's the new and
> >> innovative stuff that makes working
On Sun, 17 May 2009 20:40:37 +0200
Thomas de Grenier de Latour wrote:
> This argument is wrong imho. Future EAPIs can't be allowed to
> introduce backward-incompatible changes to the versions ordering
> rules, or they would make the PM behavior ill defined. Or, more
> precisely, if a PM adopt
Hi,
On 2009/05/17, Piotr Jaroszyński wrote:
> I have just updated GLEP 55 [1], hopefully making it a bit clearer.
In the GLEP, you raises the following argument against the "Easily
fetchable EAPI inside the ebuild" class of solutions:
> Performance decrease comes from the fact that with versio
Jorge Manuel B. S. Vicetto wrote:
> As others have commented, we should probably make this the last comment
> line in the header. Any suggestions for a specific identification string
> or do we simply use '# EAPI="X"' or use a she-bang '#!/<..> EAPI="X"' ?
Well, if a she-bang, should be the first
On Sunday 17 May 2009 20:39:26 Jorge Manuel B. S. Vicetto wrote:
> Ulrich Mueller wrote:
> >> On Sun, 17 May 2009, Denis Dupeyron wrote:
> >>
> >> 2009/5/17 Piotr Jaroszyñski :
> >>> 1. EAPI-suffixed ebuilds (obviously)
> >>> 2. EAPI in the filename with one-time extension change
> >>> 3. Easil
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ulrich Mueller wrote:
>> On Sun, 17 May 2009, Denis Dupeyron wrote:
>
>> 2009/5/17 Piotr Jaroszyñski :
>
>>> 1. EAPI-suffixed ebuilds (obviously)
>>> 2. EAPI in the filename with one-time extension change
>>> 3. Easily fetchable EAPI inside the e
Denis Dupeyron wrote:
>> 1. EAPI-suffixed ebuilds (obviously)
>> 2. EAPI in the filename with one-time extension change
>> 3. Easily fetchable EAPI inside the ebuild and one-time extension change
>
> My preference goes to 3 with a .eb extension and EAPI on the first line.
I second this. :)
On Sun, May 17, 2009 at 9:36 PM, Peter Alfredsen wrote:
> On Sun, 17 May 2009 17:56:06 +0200
> Piotr Jaroszyński wrote:
>
>> I know gentoo has other problems too, but it's the new and
>> innovative stuff that makes working on Gentoo fun.
>
> YES !
>
I sincerely hope that was sarcasm.
--
~Nirb
> On Sun, 17 May 2009, Denis Dupeyron wrote:
> 2009/5/17 Piotr Jaroszyñski :
>> 1. EAPI-suffixed ebuilds (obviously)
>> 2. EAPI in the filename with one-time extension change
>> 3. Easily fetchable EAPI inside the ebuild and one-time extension change
I'm strongly against 1 and 2 (no need to
2009/5/17 Piotr Jaroszyński :
> I have just updated GLEP 55 [1], hopefully making it a bit clearer.
Thanks a lot Piotr.
> Just FYI, my order of preference of solutions is:
>
> 1. EAPI-suffixed ebuilds (obviously)
> 2. EAPI in the filename with one-time extension change
> 3. Easily fetchable EAPI
On Sun, 17 May 2009 17:56:06 +0200
Piotr Jaroszyński wrote:
> I know gentoo has other problems too, but it's the new and
> innovative stuff that makes working on Gentoo fun.
YES !
/loki_val
Hello,
I have just updated GLEP 55 [1], hopefully making it a bit clearer.
Just FYI, my order of preference of solutions is:
1. EAPI-suffixed ebuilds (obviously)
2. EAPI in the filename with one-time extension change
3. Easily fetchable EAPI inside the ebuild and one-time extension change
I can
29 matches
Mail list logo
