Re: [gentoo-dev] GLEP 55 updated

[Ciaran McCreesh]

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 end up being
> > accepted, we'll probably be using ranged deps, so it won't be an
> > issue.
> 
> In fact, with GLEP 54 we have the problem already now.
> P=foo-1a-scm could mean both of the following:
> 
>PN=foo PV=1a-scm
>PN=foo-1a  PV=scm

We've had that problem ever since -100dpi things had to be made legal,
and the horrible mess explaining the splitting rules in PMS came about
from the last time we had this discussion. This isn't anything new --
it's just something we have to define very carefully.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] GLEP 55 updated

[Ulrich Mueller]

> 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 it won't be an
> issue.

In fact, with GLEP 54 we have the problem already now.
P=foo-1a-scm could mean both of the following:

   PN=foo PV=1a-scm
   PN=foo-1a  PV=scm

Ulrich

Re: [gentoo-dev] GLEP 55 updated

[Ciaran McCreesh]

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 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 it won't be an issue.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] GLEP 55 updated

[Ulrich Mueller]

> 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 starts?

Ulrich

Re: [gentoo-dev] GLEP 55 updated

[Ciaran McCreesh]

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 currently do. We
can't cover everything, but of these:

>1_14   -> 1.14(app-emacs/limit)
>1.0pre4-> 1.0_pre4(app-emacs/cedet)
>12B5   -> 12.2.5  (dev-lang/erlang)

These we should handle.

>1.9.1-preview1 -> 1.9.1_pre1  (app-emacs/ruby-mode)

This we could handle easily if there are more things using -preview.

>2.0b6  -> 2.0_beta6   (app-emacs/chess)

This we can't sensibly, since most people using b use it as a 'greater
than' thing.

>0.28   -> 28.0(dev-lang/c-intercal, minor.major)
>-0.74  -> ??  (SmallEiffel, negative version
> number) 1.-94.-2   -> ??  (CLC-Intercal, negative
> components)

These are upstreams being deliberately silly, so we can ignore them.

> We have to draw the borderline somewhere, and I think our current
> rules are a reasonable compromise.

Forbidding -rc is not a reasonable compromise...

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] GLEP 55 updated

[Ulrich Mueller]

> 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.0_pre4(app-emacs/cedet)
   1.9.1-preview1 -> 1.9.1_pre1  (app-emacs/ruby-mode)
   2.0b6  -> 2.0_beta6   (app-emacs/chess)
   12B5   -> 12.2.5  (dev-lang/erlang)
   0.28   -> 28.0(dev-lang/c-intercal, minor.major)
   -0.74  -> ??  (SmallEiffel, negative version number)
   1.-94.-2   -> ??  (CLC-Intercal, negative components)

We have to draw the borderline somewhere, and I think our current
rules are a reasonable compromise.

Ulrich

Re: [gentoo-dev] GLEP 55 updated

[David Leverton]

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 upgrade the package
>>> manager) works. So I don't see a need to change the file extension for
>>> this reason.
>>
>> It means we can't start using those new global scope functions until
>> we're sure that everyone's going to be upgraded, because users get
>> extremely upset if they start seeing that kind of message.
>
> Isn't that a given anyway? I think the way eapi-2 was introduced into
> the tree wasn't particularly problematic.

I think there might be a misunderstanding here. Ciaran means functions
provided by the package manager that ebuilds can call during metadata
generation, for example built-in versionator-like functionality, not
new phase functions like src_prepare and src_configure.

Re: [gentoo-dev] GLEP 55 updated

[Ciaran McCreesh]

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 parts of the tree.

Read the glibc ebuilds sometime. Notice the 'eblits' nonsense.

> > It means we can't start using those new global scope functions until
> > we're sure that everyone's going to be upgraded, because users get
> > extremely upset if they start seeing that kind of message.
> 
> Isn't that a given anyway? I think the way eapi-2 was introduced into
> the tree wasn't particularly problematic.

There's a difference between the clean "unsupported EAPIs are treated
as masked" behaviour you get with EAPIs done properly, and the horrible
spammy errors you get if they aren't. New global scope functions cause
the latter; new EAPIs done cleanly cause only the former.

> > Please explain why 1.2_rc3 is legal but 1.2-rc3 is not.
> 
> Because we say so. We have chosen to do it a certain way. This works.
> It's uniform, it's simple, and therefor has a certain beauty to it. I
> see no pressing reason why we should start allowing alternative forms.

It's an utterly arbitrary restriction. Upstreams don't standardise
either way on - vs _, so there's no reason Gentoo should.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] GLEP 55 updated

[Ben de Groot]

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 behavior with
>> eclasses in a central place works well enough. So I think we can
>> disregard this.
> 
> 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 parts of the tree.

>> 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 upgrade the package
>> manager) works. So I don't see a need to change the file extension for
>> this reason.
> 
> It means we can't start using those new global scope functions until
> we're sure that everyone's going to be upgraded, because users get
> extremely upset if they start seeing that kind of message.

Isn't that a given anyway? I think the way eapi-2 was introduced into
the tree wasn't particularly problematic.

>> 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
>> well. I don't see any need to match upstream more closely. I'd rather
>> like to keep the more uniform way of handling suffixes like rc and
>> alpha, that we have now.
> 
> Please explain why 1.2_rc3 is legal but 1.2-rc3 is not.

Because we say so. We have chosen to do it a certain way. This works.
It's uniform, it's simple, and therefor has a certain beauty to it. I
see no pressing reason why we should start allowing alternative forms.

-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
Gentoo Linux Release Engineering PR liaison
__

Re: [gentoo-dev] GLEP 55 updated

[Joe Peterson]

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
>> well. I don't see any need to match upstream more closely. I'd rather
>> like to keep the more uniform way of handling suffixes like rc and
>> alpha, that we have now.
> 
> Please explain why 1.2_rc3 is legal but 1.2-rc3 is not.

I actually like the current format in that it does *not* allow "-" in
the version.  For example, pkg-2.3.1_rc5 makes it clear that the string
from "2" to "rc5" is the version.  If were were to allow pkg-2.3.1-rc5,
this could get visually confusing (looks a bit like pkg-2.3.1-r5).  In
this case, *less* flexibility and more strict rules serve a good
purpose, I think.

-Joe

Re: [gentoo-dev] GLEP 55 updated

[Ciaran McCreesh]

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 central place works well enough. So I think we can
> disregard this.

There are already horrible hacks in the tree to get per-package
'eclasses'. That's a clear sign there's something lacking.

> 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 upgrade the package
> manager) works. So I don't see a need to change the file extension for
> this reason.

It means we can't start using those new global scope functions until
we're sure that everyone's going to be upgraded, because users get
extremely upset if they start seeing that kind of message.

> 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
> well. I don't see any need to match upstream more closely. I'd rather
> like to keep the more uniform way of handling suffixes like rc and
> alpha, that we have now.

Please explain why 1.2_rc3 is legal but 1.2-rc3 is not.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] GLEP 55 updated

[Ben de Groot]

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 this in the first place. The current inherit behavior with
eclasses in a central place works well enough. So I think we can
disregard this.

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 upgrade the package
manager) works. So I don't see a need to change the file extension for
this reason.

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
well. I don't see any need to match upstream more closely. I'd rather
like to keep the more uniform way of handling suffixes like rc and
alpha, that we have now.
GLEP54 is a valid use case, and I can see the value in that. Even so,
using - and variations has worked for us so far, so I'm not
convinced GLEP54&55 as a package is a must have.

4. "Use newer bash features"
This, in my opinion, would potentially be very useful to have. Altho it
is certainly possible to continue with bash 3.0 as we have done so far,
certain newer features are nice to be able to use.

All in all I am still not sold on the perceived problems, and therefor a
solution is in my eyes not strictly necessary. Having said that, I do
understand people wanting support for newer bash features and GLEP54, so
let's look at the possible solutions that have been proposed.


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. Easily fetchable EAPI inside the ebuild and one-time extension change
>> I'm strongly against 1 and 2 (no need to repeat the old arguments
>> here), but I could live with 3.

Me too.

>>> My preference goes to 3 with a .eb extension and EAPI on the first line.
>> Make this "the first non-empty non-comment line".
> 
> 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"' ?

In this case, I'd prefer .eb extension as well. EAPI to be somewhere
near the top, I don't care that much about the exact implementation.

>> Looks like ".eb" is already taken by some exotic commercial
>> application, but I think we can ignore this.
> 
> I like .eb but could also live with .gebuild as was suggested before.

I'd rather go for .geb as second choice. I'd rather go shorter than longer.

Robert Buchholz wrote:
> Judging from this list, fourth option present in the GLEP is 
> unacceptable for you?
> 4. Easily fetchable EAPI inside the ebuild
> 
> From what I understand, the difference between 3 and 4 is that
> 
> (4) would break pre-glep55 Portage versions that see an ebuild with no
> metadata cache present if the ebuild uses a future EAPI that 
> introduces changes as described in the "Current behaviour" section.
> (4) would otherwise keep the current workflow the same except 
> restricting the way the EAPI variable is defined in the ebuild.
> 
> I would argue that most people who are be exposed to repositories that 
> do not carry a metadata cache (overlays) which use new EAPIs also keep 
> their portage version current. I'd say go with option (4) now and by 
> the time EAPI 4 is collected, written up, agreed upon and implemented, 
> enough time went by so we would not have to introduce an artificial 
> delay.
> And after that, there won't be any delay to avoid breakage anymore.

This would still have my preference.

Cheers,
-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
Gentoo Linux Release Engineering PR liaison
__

Re: [gentoo-dev] GLEP 55 updated

[Ciaran McCreesh]

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.
> 
> I understand the idea, but I still don't think it's viable to allow
> such definitions, because there are too many contexts in which we
> manipulate pure version strings, without decorating them with an EAPI,
> and without reference to a concrete package from which we could get
> it. Take ">=bar/foo-1_p" as an "emerge" command line argument for
> instance, is my foo-1_p1.ebuild a candidate?

Conceptually, you'd define a 'user' EAPI for those things, so you can
define it any way you want (including in such a way that the _p thing
works both ways depending upon the EAPI used for creating the thing
you're comparing it to -- for the user EAPI, you'd define it as being
_pUNSPECIFIED rather than _p0 or _pINFINITY and use the other side of
the comparison to decide the result). But yes, if you do something
silly like your example, things get very complicated.

> > > As a consequence, the algorithm for picking best version of a
> > > package can be as simple as the following:
> > >  1- among all ebuilds filenames, filter out the ones with
> > > unrecognized version string
> > 
> > You don't know whether you recognise the version string until you
> > know the EAPI, though.
> 
> Under my previously stated restrictions, you know:
>  - which one can be rejected for sure (the ones not recognized by any
>of your implemented EAPI).
>  - how to correctly order the remaining ones (even the incorrect ones
>which may remain and would be rejected only at step 4), and thus
>where to start to find the "best" correct one.

Your previously stated restrictions are too strong, though. And when it
turns out a future change breaks those restrictions, we'd be back to
yet another extension change.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] GLEP 55 updated

[Thomas de Grenier de Latour]

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 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.

I understand the idea, but I still don't think it's viable to allow
such definitions, because there are too many contexts in which we
manipulate pure version strings, without decorating them with an EAPI,
and without reference to a concrete package from which we could get it.
Take ">=bar/foo-1_p" as an "emerge" command line argument for
instance, is my foo-1_p1.ebuild a candidate?

> Although that's a fairly convoluted example, and not in line with
> what's being proposed for future EAPIs. What we're after is the
> ability to allow versions like 1.2.3-rc1.

Right, and for this kind of reasonable future needs, it's easy enough 
to ensure enough backward compatibility so that we don't need to add 
the EAPI each time we talk about a version.

> > As a consequence, the algorithm for picking best version of a
> > package can be as simple as the following:
> >  1- among all ebuilds filenames, filter out the ones with
> > unrecognized version string
> 
> You don't know whether you recognise the version string until you know
> the EAPI, though.

Under my previously stated restrictions, you know:
 - which one can be rejected for sure (the ones not recognized by any
   of your implemented EAPI).
 - how to correctly order the remaining ones (even the incorrect ones
   which may remain and would be rejected only at step 4), and thus
   where to start to find the "best" correct one.
Which is well enough.

--
TGL.

Re: [gentoo-dev] GLEP 55 updated

[Piotr Jaroszyński]

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-time extension change
>> 3. Easily fetchable EAPI inside the ebuild and one-time extension
>> change
>
> Judging from this list, fourth option present in the GLEP is
> unacceptable for you?

I would like to avoid user-visible breakage as much as possible.

-- 
Best Regards,
Piotr Jaroszyński

Re: [gentoo-dev] GLEP 55 updated

[Arfrever Frehtes Taifersar Arahesis]

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 in the filename with one-time extension change
> > 3. Easily fetchable EAPI inside the ebuild and one-time extension
> > change
> 
> Judging from this list, fourth option present in the GLEP is 
> unacceptable for you?
> 4. Easily fetchable EAPI inside the ebuild

+1

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] GLEP 55 updated

[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-time extension change
> 3. Easily fetchable EAPI inside the ebuild and one-time extension
> change

Judging from this list, fourth option present in the GLEP is 
unacceptable for you?
4. Easily fetchable EAPI inside the ebuild

From what I understand, the difference between 3 and 4 is that

(4) would break pre-glep55 Portage versions that see an ebuild with no
metadata cache present if the ebuild uses a future EAPI that 
introduces changes as described in the "Current behaviour" section.
(4) would otherwise keep the current workflow the same except 
restricting the way the EAPI variable is defined in the ebuild.

I would argue that most people who are be exposed to repositories that 
do not carry a metadata cache (overlays) which use new EAPIs also keep 
their portage version current. I'd say go with option (4) now and by 
the time EAPI 4 is collected, written up, agreed upon and implemented, 
enough time went by so we would not have to introduce an artificial 
delay.
And after that, there won't be any delay to avoid breakage anymore.


Robert


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] GLEP 55 updated

[Peter Alfredsen]

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 Gentoo fun.
> >
> > YES !
> >
> 
> I sincerely hope that was sarcasm.

I don't want us to get to a place where every single new feature has to
be delayed by the objection "We've got basic bugs we need to fix
first." That's just unreasonable and a straw man. I get my kicks from
improving things, not from fixing broken things. You may object and say
they're one and the same, and you would not be wrong, but the emphasis
*is* different.

People seem to not see that in the case of GLEP 55 and some call for a
moratorium on new features till we've fixed the bugs that already
exist. Not gonna happen. The human spirit is what's driving Gentoo,
giving it life. Our aspirations to improve the world around us lives
and breathes with every ebuild we churn out. World domination is our
goal and we won't get there by letting the maintainer-needed queue bog
us down.

I think that it's obvious to everybody that the problem GLEP 55 is
solving is real. To me, .ebuild-$eapi/.eapi-$eapi.eb looks like the best
solution, all things considered. From a purely unixy point-of-view, I
see the cleanliness of a shebang EAPI definition, and that would be my
second choice, but we need a solution we can use now. Not a year from
now. Time really does matter.

My dislike for the GLEP 55 process is my main reason for supporting
GLEP 55 as-is. If we can skip just one more 50-mail thread because of
GLEP55, it will be worth the extra work of typing -$eapi every now and
then. Because seriously, if ever there was a mailing list topic whose
only effect has been to act like a succubus, GLEP 55 is it.

( In other words: No sarcasm intended )

/loki_val

Re: [gentoo-dev] GLEP 55 updated

[Ciaran McCreesh]

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 adopts an EAPI with such a change, it has to drop
> support for the older incompatible ones.

Not exactly true. It means that EAPI version rules have to be mappable
onto a single larger superversion format in such a way that they have a
total order.

> 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 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.

Although that's a fairly convoluted example, and not in line with
what's being proposed for future EAPIs. What we're after is the ability
to allow versions like 1.2.3-rc1.

> As a consequence, the algorithm for picking best version of a package
> can be as simple as the following:
>  1- among all ebuilds filenames, filter out the ones with unrecognized
> version string

You don't know whether you recognise the version string until you know
the EAPI, though.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] GLEP 55 updated

[Thomas de Grenier de Latour]

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 version format 
> changes in the picture package managers need EAPI to parse the 
> ebuild's version.  That means that merely picking the best version
> of a package requires loading EAPI (from cache or the ebuild) for 
> each available ebuild.

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 adopts an EAPI with such a change, it has to drop
support for the older incompatible ones. 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?

So, basically, we are, and will stay, in a situation such that there 
is a complete order relation beetween all the version strings 
supported by at least one of the EAPIs implemented by the PM, and all
the versionning rules of this EAPIs match this order relation.

As a consequence, the algorithm for picking best version of a package
can be as simple as the following:
 1- among all ebuilds filenames, filter out the ones with unrecognized
version string
 2- among the remaining ones, parse and sort versions (sure, would 
actually be done together with step 1, for performances reasons)
 3- get metadatas for the best one (generate or pick in cache), and 
check its EAPI that it is a supported one, and also that the version
string is allowed in this EAPI
 4- loop on step 3 if EAPI check failed

It is as fast as the algorithm GLEP55 promotes, but in the case you're
using an old package manager and there is really a lot of ebuild 
updates you skip because of unsupported EAPI (here you still fetch 
their metadata, but not with GLEP55).  But i don't see it as a nominal
case. 


Thanks,
--
TGL.

Re: [gentoo-dev] GLEP 55 updated

[Joe Peterson]

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 line.  That also makes parsing a lot
more straightforward and easily defined.

>> Looks like ".eb" is already taken by some exotic commercial
>> application, but I think we can ignore this.
> 
> I like .eb but could also live with .gebuild as was suggested before.

I'd hate to see the length grow - shrinking is better and cleaner.  :)
.gebuild is a little unwieldy IMHO.  Also, since ebuilds can be used with
distros other than gentoo itself, having the "g" there may not be a good idea.

-Joe

Re: [gentoo-dev] GLEP 55 updated

[Markos Chandras]

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. Easily fetchable EAPI inside the ebuild and one-time extension
> >>> change
> >
> > I'm strongly against 1 and 2 (no need to repeat the old arguments
> > here), but I could live with 3.
>
> I also prefer 3.
>
> >> My preference goes to 3 with a .eb extension and EAPI on the first line.
> >
> > Make this "the first non-empty non-comment line".
>
> 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"' ?
Yeah, this sounds pretty reasonable to me :)

-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer [KDE/Qt/Sound/Sunrise]
Web: http://hwoarang.silverarrow.org


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] GLEP 55 updated

[Jorge Manuel B. S. Vicetto]

-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 ebuild and one-time extension change
> 
> I'm strongly against 1 and 2 (no need to repeat the old arguments
> here), but I could live with 3.

I also prefer 3.

>> My preference goes to 3 with a .eb extension and EAPI on the first line.
> 
> Make this "the first non-empty non-comment line".

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"' ?

> Looks like ".eb" is already taken by some exotic commercial
> application, but I think we can ignore this.

I like .eb but could also live with .gebuild as was suggested before.

> Ulrich
> 
> [1] 
> 

- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoQS84ACgkQcAWygvVEyAJ2gwCfUXuvc1f995QTxkElrPlY9I1H
R6oAn0CMpXBe4Y8qnbkCleS3CgNbHJcK
=kwqB
-END PGP SIGNATURE-

Re: [gentoo-dev] GLEP 55 updated

[Joe Peterson]

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.    :)  Although I do not have a strong preference of in-file
position, first line makes it like a she-bang, and that sounds good all around.

-Joe

Re: [gentoo-dev] GLEP 55 updated

[Nirbheek Chauhan]

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.


-- 
~Nirbheek Chauhan

Re: [gentoo-dev] GLEP 55 updated

[Ulrich Mueller]

> 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 repeat the old arguments
here), but I could live with 3.

> My preference goes to 3 with a .eb extension and EAPI on the first line.

Make this "the first non-empty non-comment line".

Looks like ".eb" is already taken by some exotic commercial
application, but I think we can ignore this.

Ulrich

[1] 

Re: [gentoo-dev] GLEP 55 updated

[Denis Dupeyron]

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 inside the ebuild and one-time extension change

My preference goes to 3 with a .eb extension and EAPI on the first line.

> P.S. I know gentoo has other problems too, but it's the new and
> innovative stuff that makes working on Gentoo fun.

We need all the problem solving people we can get. And since we're all
volunteers there's no way we can force anybody to do anything. So,
sure, there may be a need for prioritizing problems, but one problem
solved is one less on the pile whatever it was.

Denis.

Re: [gentoo-dev] GLEP 55 updated

[Peter Alfredsen]

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