[gentoo-dev] GLEP 55 updated

[gentoo-dev] GLEP 55 updated

[Piotr Jaroszyński]

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 live with any of these if that's what it takes to move forward.

Imho, council should first vote on whether they see the problem
described in the GLEP as real (do we all agree on that at least?) and
then pick one of these solutions.

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

[1] - http://dev.gentoo.org/~peper/glep-0055.html
(http://www.gentoo.org/proj/en/glep/glep-0055.html once it synces)

-- 
Best Regards,
Piotr Jaroszyński

Re: [gentoo-dev] GLEP 55 updated

[Peter Alfredsen]

On Sun, 17 May 2009 17:56:06 +0200
Piotr Jaroszyński <peper@gentoo.org> 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

Re: [gentoo-dev] GLEP 55 updated

[Nirbheek Chauhan]

On Sun, May 17, 2009 at 9:36 PM, Peter Alfredsen <loki_val@gentoo.org> wrote:
> On Sun, 17 May 2009 17:56:06 +0200
> Piotr Jaroszyński <peper@gentoo.org> 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

[Peter Alfredsen]

On Sun, 17 May 2009 22:54:38 +0530
Nirbheek Chauhan <nirbheek@gentoo.org> wrote:

> On Sun, May 17, 2009 at 9:36 PM, Peter Alfredsen
> <loki_val@gentoo.org> wrote:
> > On Sun, 17 May 2009 17:56:06 +0200
> > Piotr Jaroszyński <peper@gentoo.org> 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

[Denis Dupeyron]

2009/5/17 Piotr Jaroszyński <peper@gentoo.org>:
> 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

[Ulrich Mueller]

>>>>> On Sun, 17 May 2009, Denis Dupeyron wrote:

> 2009/5/17 Piotr Jaroszyñski <peper@gentoo.org>:

>> 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] <http://filext.com/file-extension/EB>

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 <peper@gentoo.org>:
> 
>>> 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] <http://filext.com/file-extension/EB>
> 

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

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]

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 <peper@gentoo.org>:
> >>> 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[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 -9999 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 <peper@gentoo.org>:
>>>> 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]

[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]

On Sun, 17 May 2009 23:17:57 +0200
Ben de Groot <yngwin@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[gentoo-dev] Re: GLEP 55 updated

[Steven J Long]

Joe Peterson wrote:

> 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.
> 
Agreed; the purpose of an internal format specification is not to allow
NN variants on a theme all over the place. It should nail things
down to ONE variant which everybody can collaborate around.

I missed the clamour of developers complaining about this oh-so-burdensome
restriction that they've been dealing with for at least 5 years. Until I see
that happening independently of this current hooha, I'm going to consider
this 'reason' to be yaf "straw man".

-- 
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: GLEP 55 updated

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 390 bytes --]

On Mon, 18 May 2009 16:07:20 +0100
Steven J Long <slong@rathaus.eclipse.co.uk> wrote:
> I missed the clamour of developers complaining about this
> oh-so-burdensome restriction that they've been dealing with for at
> least 5 years.

Why do you think I wrote the awful hack that is versionator?

Anything that finally lets us kill that off has to be good...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: versionator.eclass terminator, was [gentoo-dev] Re: GLEP 55 updated

[Jeroen Roovers]

On Mon, 18 May 2009 16:16:46 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> Why do you think I wrote the awful hack that is versionator?

Why don't you explain why, historically, you put that in the tree? It
would help us now if you were to simply record your mistakes for
everybody else to easily avoid. It's still being used in the tree and
should be discouraged.

> Anything that finally lets us kill that off has to be good...

Loosening VERSION requirements won't fix the problem. This will:

1) Discourage its use by putting a QA ewarn in the eclass.
2) Have all ebuilds converted either through QA bugs or a nice Saturday
afternoon coding spree.
3) Announce its removal.
4) Remove.

Re: versionator.eclass terminator, was [gentoo-dev] Re: GLEP 55 updated

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2054 bytes --]

On Mon, 18 May 2009 17:28:00 +0200
Jeroen Roovers <jer@gentoo.org> wrote:
> On Mon, 18 May 2009 16:16:46 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > Why do you think I wrote the awful hack that is versionator?
> 
> Why don't you explain why, historically, you put that in the tree? It
> would help us now if you were to simply record your mistakes for
> everybody else to easily avoid. It's still being used in the tree and
> should be discouraged.

Versionator was created because the alternative was worse: developers
were hard-coding versions in ebuilds, writing dodgy bash substitutions
that wouldn't reliably convert between versions and using things like
sed and tr in global scope.

The problem is, versionator was written before the current version
rules. It doesn't handle some things that are now legal, and it still
uses the old meanings for numeric components.

The correct solution is two-fold:

* Replace versionator with package-manager internal functions that use
  the package manager's rules for version parsing.

* Reduce the need to use MY_PV by extending the version rules.

Both of these are things that can't be done with current EAPI rules.

> > Anything that finally lets us kill that off has to be good...
> 
> Loosening VERSION requirements won't fix the problem. This will:
> 
> 1) Discourage its use by putting a QA ewarn in the eclass.
> 2) Have all ebuilds converted either through QA bugs or a nice
> Saturday afternoon coding spree.
> 3) Announce its removal.
> 4) Remove.

You can't discourage versionator until the replacement's in place.
Going back to the old way of doing things is a loooooot worse than
using versionator. So no, the way to fix it is:

1) Change the EAPI rules to allow global scope and version suffix
changes.

2) Bring in a versionator replacement done as internals in a new EAPI.

3) Extend the version format rules in a new EAPI.

4) Disallow versionator use in the first EAPI that has 2) and 3).

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: versionator.eclass terminator, was [gentoo-dev] Re: GLEP 55 updated

[Robert Buchholz]

[-- Attachment #1: Type: text/plain, Size: 550 bytes --]

On Monday 18 May 2009, Jeroen Roovers wrote:
> On Mon, 18 May 2009 16:16:46 +0100
>
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > Why do you think I wrote the awful hack that is versionator?
>
> Why don't you explain why, historically, you put that in the tree? It
> would help us now if you were to simply record your mistakes for
> everybody else to easily avoid. It's still being used in the tree and
> should be discouraged.

I'm not following. Why should it be discouraged? 
I was happy with it until now.

Robert

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: versionator.eclass terminator, was [gentoo-dev] Re: GLEP 55 updated

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

On Mon, 18 May 2009 17:42:19 +0200
Robert Buchholz <rbu@gentoo.org> wrote:
> I'm not following. Why should it be discouraged? 
> I was happy with it until now.

Versionator is a lot better than what people were doing before I wrote
it. It's just nowhere near as good as what a package manager provided
solution combined with a reduced need for MY_PV hacks would give.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Re: GLEP 55 updated

[Joe Peterson]

Ciaran McCreesh wrote:
> On Mon, 18 May 2009 16:07:20 +0100
> Steven J Long <slong@rathaus.eclipse.co.uk> wrote:
>> I missed the clamour of developers complaining about this
>> oh-so-burdensome restriction that they've been dealing with for at
>> least 5 years.
> 
> Why do you think I wrote the awful hack that is versionator?
> Anything that finally lets us kill that off has to be good...

I have to disagree.  As Steve said, the fact that Gentoo has a strict
way to specify versions brings clarity and uniformity to our tree,
regardless of the myriad upstream conventions.  I do not think that
allowing all of those upstream conventions in our filenames is a
benefit.  It is actually quite ugly and would make the tree harder to
comprehend.  Someone looking at various packages in our tree would need
to learn each specific upstream format in order to make sense of the
filename content.  The current consistency in versions in the tree is a
great feature, IMHO.

Using versionator and $MY_PV is, as I see it, a translation method.  It
gives us the best of both worlds: the ability to deal with upstream
versions and a consistent Gentoo version format.  These mechanisms could
certainly be improved upon, of course, and handling some cases is
currently difficult, as is handing the case in which upstream's tarball
file does not contain the version, but these are fixable issues.

						-Joe

Re: [gentoo-dev] GLEP 55 updated

[Ben de Groot]

Ciaran McCreesh wrote:
> On Sun, 17 May 2009 23:17:57 +0200
> Ben de Groot <yngwin@gentoo.org> 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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]

On Mon, 18 May 2009 00:08:05 +0200
Ben de Groot <yngwin@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1322 bytes --]

On Mon, 18 May 2009 00:54:04 +0200
Ulrich Mueller <ulm@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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]

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]

On Mon, 18 May 2009 01:11:45 +0200
Ulrich Mueller <ulm@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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]

[-- Attachment #1: Type: text/plain, Size: 881 bytes --]

On Mon, 18 May 2009 01:30:26 +0200
Ulrich Mueller <ulm@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] GLEP 54 and hyphens in PV (was: GLEP 55 updated)

[Ulrich Mueller]

>>>>> On Mon, 18 May 2009, Ciaran McCreesh wrote:

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

But so far you can split P into PN and PV at the last hyphen, because
it is guaranteed that PV contains no hyphens.

Trouble starts if hyphens in PV are allowed.

Ulrich

Re: [gentoo-dev] GLEP 54 and hyphens in PV (was: GLEP 55 updated)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 398 bytes --]

On Mon, 18 May 2009 01:43:43 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> Trouble starts if hyphens in PV are allowed.

You mean like -r0?

It's easily solved by a careful definition, in any case, just the same
way that there's already a careful definition full of weaselling out to
allow other abuses... There's no ambiguity so long as the definition is
sound.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] GLEP 54 and hyphens in PV

[Ulrich Mueller]

>>>>> On Mon, 18 May 2009, Ciaran McCreesh wrote:

>> Trouble starts if hyphens in PV are allowed.

> You mean like -r0?

The revision is not part of PV. And it's easily split off, since the
string "-r<digits>" cannot occur elsewhere in the package version.

> It's easily solved by a careful definition, in any case, just the
> same way that there's already a careful definition full of
> weaselling out to allow other abuses... There's no ambiguity so long
> as the definition is sound.

To come back to my example:

>> P=foo-1a-scm could mean both of the following:
>> 
>> PN=foo     PV=1a-scm
>> PN=foo-1a  PV=scm

AFAICS, there _is_ an ambiguity. You can have the following two
ebuilds in the tree, simultaneously:

   ${PORTDIR}/app-misc/foo/foo-1a-scm.ebuild
   ${PORTDIR}/app-misc/foo-1a/foo-1a-scm.ebuild

Which package will be pulled in by the following dependency?

   RDEPEND="=app-misc/foo-1a-scm"

The conclusion is that GLEP 54 in its current form is not implementable.
(But maybe it would be possible to use a period instead of the hyphen?
That is, ".live" instead of "-scm"?)

Ulrich

Re: [gentoo-dev] GLEP 54 and hyphens in PV

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 197 bytes --]

On Mon, 18 May 2009 06:59:36 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> AFAICS, there _is_ an ambiguity.

There's no ambiguity. It means what we define it to mean.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] GLEP 54 and hyphens in PV

[Ulrich Mueller]

>>>>> On Mon, 18 May 2009, Ciaran McCreesh wrote:

> On Mon, 18 May 2009 06:59:36 +0200
> Ulrich Mueller <ulm@gentoo.org> wrote:
>> AFAICS, there _is_ an ambiguity. You can have the following two
>> ebuilds in the tree, simultaneously:

>>    ${PORTDIR}/app-misc/foo/foo-1a-scm.ebuild
>>    ${PORTDIR}/app-misc/foo-1a/foo-1a-scm.ebuild

[Added some context back to your quotation of my posting.]

> There's no ambiguity. It means what we define it to mean.

Maybe it's possible to do that for dependencies, but VDB entries and
binary packages for above two examples would still collide.

So the conclusion still stands:

>> The conclusion is that GLEP 54 in its current form is not
>> implementable.

Hyphens within PV are a Bad Thing, and we should really think about
replacing the separator for "scm" by something else, like a period or
an underscore. For example, the following two would be unique:

    ${PORTDIR}/app-misc/foo/foo-1a_live.ebuild
    ${PORTDIR}/app-misc/foo-1a/foo-1a-live.ebuild

With our current versioning scheme the rule is very simple: ${P} is
split into ${PN} and ${PV} at the last hyphen. This can be done in a
straight forward way by regexp matching, and I would really hate to
lose this nice property.

Ulrich

Re: [gentoo-dev] GLEP 54 and hyphens in PV

[Joe Peterson]

Ulrich Mueller wrote:
> Hyphens within PV are a Bad Thing, and we should really think about
> replacing the separator for "scm" by something else, like a period or
> an underscore. For example, the following two would be unique:
> 
>     ${PORTDIR}/app-misc/foo/foo-1a_live.ebuild
>     ${PORTDIR}/app-misc/foo-1a/foo-1a-live.ebuild
> 
> With our current versioning scheme the rule is very simple: ${P} is
> split into ${PN} and ${PV} at the last hyphen. This can be done in a
> straight forward way by regexp matching, and I would really hate to
> lose this nice property.

Underscore probably makes most sense, since it is similar to the
underscore used in _rc3, etc.  Of course, don't use an "_" when it's
just "live" alone.  I agree, especially if we consider "live"
essentially part of the version (as "9999" is now), and especially since
it's possible to have simply a version of "live" with no numeric
portion, that it should avoid the "-".  Not sure I like "."...

					-Joe

Re: [gentoo-dev] GLEP 54 and hyphens in PV

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]

On Wed, May 20, 2009 at 5:01 AM, Ulrich Mueller <ulm@gentoo.org> wrote:

>
>
>    ${PORTDIR}/app-misc/foo/foo-1a_live.ebuild
>    ${PORTDIR}/app-misc/foo-1a/foo-1a-live.ebuild
>
> With our current versioning scheme the rule is very simple: ${P} is
> split into ${PN} and ${PV} at the last hyphen. This can be done in a
> straight forward way by regexp matching, and I would really hate to
> lose this nice property.
>
> Ulrich
>
>

$str="app-misc/foo/foo-1a_live.ebuild";
$str =~ /([^/]+)/([^/]+)/\2(.*).ebuild/
( $category, $package, $version ) = ( $1, $2, $3 )

Simple enough on a supporting language. Naive maybe, but has worked well for
me thus far.

It appears to be more a problem disambiguating from the user-input end of
the spectrum, and this scenario would be more likely to happen if for some
insane crack-fueled reason both packages were to exist. Even then,

app-misc/foo-1a  # must always resolve to "app-misc/foo-1a" due to no =
stating that it needs a version part
=app-misc/foo-1a # must always resolve to "app-misc/foo" due to the =
stating a mandatory version part.  ( =cat/pack is invalid )

-- 
Kent

[-- Attachment #2: Type: text/html, Size: 1542 bytes --]

Re: [gentoo-dev] GLEP 54 and hyphens in PV

[Tiziano Müller]

[-- Attachment #1: Type: text/plain, Size: 1968 bytes --]

Am Dienstag, den 19.05.2009, 19:01 +0200 schrieb Ulrich Mueller:
> >>>>> On Mon, 18 May 2009, Ciaran McCreesh wrote:
> 
> > On Mon, 18 May 2009 06:59:36 +0200
> > Ulrich Mueller <ulm@gentoo.org> wrote:
> >> AFAICS, there _is_ an ambiguity. You can have the following two
> >> ebuilds in the tree, simultaneously:
> 
> >>    ${PORTDIR}/app-misc/foo/foo-1a-scm.ebuild
> >>    ${PORTDIR}/app-misc/foo-1a/foo-1a-scm.ebuild

> [Added some context back to your quotation of my posting.]
> 
> > There's no ambiguity. It means what we define it to mean.
> 
> Maybe it's possible to do that for dependencies, but VDB entries and
> binary packages for above two examples would still collide.
> 
> So the conclusion still stands:
> 
> >> The conclusion is that GLEP 54 in its current form is not
> >> implementable.
> 
> Hyphens within PV are a Bad Thing, and we should really think about
> replacing the separator for "scm" by something else, like a period or
> an underscore. For example, the following two would be unique:
> 
>     ${PORTDIR}/app-misc/foo/foo-1a_live.ebuild
>     ${PORTDIR}/app-misc/foo-1a/foo-1a-live.ebuild
you probably mean:
${PORTDIR}/app-misc/foo-1a/foo-1a.live.ebuild

but how would their vdb or binpkg names be unique?

vdb for example:
app-misc/foo-1a_live for app-misc/foo
app-misc/foo-1a_live for app-misc/foo-1a

am I missing something?

> 
> With our current versioning scheme the rule is very simple: ${P} is
> split into ${PN} and ${PV} at the last hyphen. This can be done in a
> straight forward way by regexp matching, and I would really hate to
> lose this nice property.

I don't understand why this property is important. Can you please
explain?


-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] GLEP 54 and hyphens in PV

[Ulrich Mueller]

>>>>> On Thu, 28 May 2009, Tiziano Müller wrote:

>> ${PORTDIR}/app-misc/foo/foo-1a_live.ebuild
>> ${PORTDIR}/app-misc/foo-1a/foo-1a-live.ebuild

> you probably mean:
> ${PORTDIR}/app-misc/foo-1a/foo-1a.live.ebuild

No, I mean what I had written, namely to use an underscore as
separator, i.e., "_live". But when the version is just "live" alone,
one would suppress the underscore for aesthetic reasons, i.e. instead
of "foo-1a-_live" it would be "foo-1a-live".

> but how would their vdb or binpkg names be unique?

> vdb for example:
> app-misc/foo-1a_live for app-misc/foo

PN=foo, PV=1a_live => app-misc/foo-1a_live

> app-misc/foo-1a_live for app-misc/foo-1a

PN=foo-1a, PV=live => app-misc/foo-1a-live

> am I missing something?

Everything is easy, if you keep the following rule in mind:

>> With our current versioning scheme the rule is very simple: ${P} is
>> split into ${PN} and ${PV} at the last hyphen. This can be done in
>> a straight forward way by regexp matching, and I would really hate
>> to lose this nice property.

> I don't understand why this property is important. Can you please
> explain?

See above, it automatically avoids any ambiguities in splitting P into
PN and PV. And look at function "pkgsplit" in Portage: It can just
treat PV as an opaque string.

What would be the advantage to use a hyphen instead of an underscore?

Ulrich

Re: [gentoo-dev] GLEP 54 and hyphens in PV

[Piotr Jaroszyński]

2009/5/28 Ulrich Mueller <ulm@gentoo.org>:
>>>>>> On Thu, 28 May 2009, Tiziano Müller wrote:
>
>>> ${PORTDIR}/app-misc/foo/foo-1a_live.ebuild
>>> ${PORTDIR}/app-misc/foo-1a/foo-1a-live.ebuild
>
>> you probably mean:
>> ${PORTDIR}/app-misc/foo-1a/foo-1a.live.ebuild
>
> No, I mean what I had written, namely to use an underscore as
> separator, i.e., "_live". But when the version is just "live" alone,
> one would suppress the underscore for aesthetic reasons, i.e. instead
> of "foo-1a-_live" it would be "foo-1a-live".
>
>> but how would their vdb or binpkg names be unique?
>
>> vdb for example:
>> app-misc/foo-1a_live for app-misc/foo
>
> PN=foo, PV=1a_live => app-misc/foo-1a_live
>
>> app-misc/foo-1a_live for app-misc/foo-1a
>
> PN=foo-1a, PV=live => app-misc/foo-1a-live
>
>> am I missing something?
>
> Everything is easy, if you keep the following rule in mind:
>
>>> With our current versioning scheme the rule is very simple: ${P} is
>>> split into ${PN} and ${PV} at the last hyphen. This can be done in
>>> a straight forward way by regexp matching, and I would really hate
>>> to lose this nice property.
>
>> I don't understand why this property is important. Can you please
>> explain?
>
> See above, it automatically avoids any ambiguities in splitting P into
> PN and PV. And look at function "pkgsplit" in Portage: It can just
> treat PV as an opaque string.
>
> What would be the advantage to use a hyphen instead of an underscore?

Mainly the thing you observed yourself - foo_live is a bit
inconsistent with current versions.

The case you mention can be avoided with another restriction in PMS.
Buut we might as well go all the way and change the version separator
to -- or something, which would be the most flexible.

-- 
Best Regards,
Piotr Jaroszyński

Re: [gentoo-dev] GLEP 54 and hyphens in PV

[Marijn Schouten (hkBst)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Piotr Jaroszyński wrote:
> 2009/5/28 Ulrich Mueller <ulm@gentoo.org>:
>>>>>>> On Thu, 28 May 2009, Tiziano Müller wrote:
>>>> ${PORTDIR}/app-misc/foo/foo-1a_live.ebuild
>>>> ${PORTDIR}/app-misc/foo-1a/foo-1a-live.ebuild
>>> you probably mean:
>>> ${PORTDIR}/app-misc/foo-1a/foo-1a.live.ebuild
>> No, I mean what I had written, namely to use an underscore as
>> separator, i.e., "_live". But when the version is just "live" alone,
>> one would suppress the underscore for aesthetic reasons, i.e. instead
>> of "foo-1a-_live" it would be "foo-1a-live".
>>
>>> but how would their vdb or binpkg names be unique?
>>> vdb for example:
>>> app-misc/foo-1a_live for app-misc/foo
>> PN=foo, PV=1a_live => app-misc/foo-1a_live
>>
>>> app-misc/foo-1a_live for app-misc/foo-1a
>> PN=foo-1a, PV=live => app-misc/foo-1a-live
>>
>>> am I missing something?
>> Everything is easy, if you keep the following rule in mind:
>>
>>>> With our current versioning scheme the rule is very simple: ${P} is
>>>> split into ${PN} and ${PV} at the last hyphen. This can be done in
>>>> a straight forward way by regexp matching, and I would really hate
>>>> to lose this nice property.
>>> I don't understand why this property is important. Can you please
>>> explain?
>> See above, it automatically avoids any ambiguities in splitting P into
>> PN and PV. And look at function "pkgsplit" in Portage: It can just
>> treat PV as an opaque string.
>>
>> What would be the advantage to use a hyphen instead of an underscore?
> 
> Mainly the thing you observed yourself - foo_live is a bit
> inconsistent with current versions.

Ulrich is proposing foo-live if live is the entire version, foo_live is not a
legal `package name and version'. (It could be a package name though.)

> The case you mention can be avoided with another restriction in PMS.
> Buut we might as well go all the way and change the version separator
> to -- or something, which would be the most flexible.

That would also be a good solution though we don't seem to need it yet. It would
also entail compatibility issues.

Marijn

- --
If you cannot read my mind, then listen to what I say.

Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoeqg0ACgkQp/VmCx0OL2zn2gCfZl0knh8Er2x1B8PrbdwWSYHU
b/MAnj3pYO2qzXhUx+z1w9Vnrdf2/uJo
=EzB3
-----END PGP SIGNATURE-----

Re: [gentoo-dev] GLEP 54 and hyphens in PV

[Piotr Jaroszyński]

2009/5/28 Marijn Schouten (hkBst) <hkBst@gentoo.org>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Piotr Jaroszyński wrote:
>> 2009/5/28 Ulrich Mueller <ulm@gentoo.org>:
>>>>>>>> On Thu, 28 May 2009, Tiziano Müller wrote:
>>>>> ${PORTDIR}/app-misc/foo/foo-1a_live.ebuild
>>>>> ${PORTDIR}/app-misc/foo-1a/foo-1a-live.ebuild
>>>> you probably mean:
>>>> ${PORTDIR}/app-misc/foo-1a/foo-1a.live.ebuild
>>> No, I mean what I had written, namely to use an underscore as
>>> separator, i.e., "_live". But when the version is just "live" alone,
>>> one would suppress the underscore for aesthetic reasons, i.e. instead
>>> of "foo-1a-_live" it would be "foo-1a-live".
>>>
>>>> but how would their vdb or binpkg names be unique?
>>>> vdb for example:
>>>> app-misc/foo-1a_live for app-misc/foo
>>> PN=foo, PV=1a_live => app-misc/foo-1a_live
>>>
>>>> app-misc/foo-1a_live for app-misc/foo-1a
>>> PN=foo-1a, PV=live => app-misc/foo-1a-live
>>>
>>>> am I missing something?
>>> Everything is easy, if you keep the following rule in mind:
>>>
>>>>> With our current versioning scheme the rule is very simple: ${P} is
>>>>> split into ${PN} and ${PV} at the last hyphen. This can be done in
>>>>> a straight forward way by regexp matching, and I would really hate
>>>>> to lose this nice property.
>>>> I don't understand why this property is important. Can you please
>>>> explain?
>>> See above, it automatically avoids any ambiguities in splitting P into
>>> PN and PV. And look at function "pkgsplit" in Portage: It can just
>>> treat PV as an opaque string.
>>>
>>> What would be the advantage to use a hyphen instead of an underscore?
>>
>> Mainly the thing you observed yourself - foo_live is a bit
>> inconsistent with current versions.
>
> Ulrich is proposing foo-live if live is the entire version, foo_live is not a
> legal `package name and version'. (It could be a package name though.)

I know, it's also inconsistent. Anyway that's really not that
important. We could forbid package names that end with a -$PV where
$PV is a valid version spec. That would make package names like foo-1b
invalid (didn't see anything named like that in the tree anyway).

>> The case you mention can be avoided with another restriction in PMS.
>> Buut we might as well go all the way and change the version separator
>> to -- or something, which would be the most flexible.
>
> That would also be a good solution though we don't seem to need it yet. It would
> also entail compatibility issues.

Not with g55.

-- 
Best Regards,
Piotr Jaroszyński

Re: [gentoo-dev] GLEP 55 updated

[David Leverton]

2009/5/17 Ben de Groot <yngwin@gentoo.org>:
> Ciaran McCreesh wrote:
>> On Sun, 17 May 2009 23:17:57 +0200
>> Ben de Groot <yngwin@gentoo.org> 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.

[gentoo-dev] Re: GLEP 55 updated

[Steven J Long]

David Leverton wrote:

> 2009/5/17 Ben de Groot <yngwin@gentoo.org>:
>> 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.

Ugh. Firstly versionator is a piece of bloated crap that should have died a
long time ago; all it does is stop Gentoo newbs learning the basics[1] of
their implementation language, which leaves them open to nonsensical
arguments about printf -v (glad you finally learnt that one, btw.)

Secondly, please explain fully and clearly, but concisely, why we can't
simply state that EAPI=NN allows the ebuild to use the EAPI functions in
global scope.

Bear in mind that you have to deal with the case of the mangler which can
get EAPI from an ebuild without sourcing, as portage currently can, I
believe.

Relaxing that restriction strikes me as much saner than relaxing all the
other restrictions which make interoperability easier.

(Frankly, I'm amazed at having to state that to people trusted to write a
specification. Follow up to -project on this point please, as it's about
process, not technique.)

[1] (watch wrap)
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_02
http://wooledge.org/mywiki/BashFAQ/073
man bash /Parameter Expansion

--
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: GLEP 55 updated

[David Leverton]

2009/5/18 Steven J Long <slong@rathaus.eclipse.co.uk>:
> David Leverton wrote:
>
>> 2009/5/17 Ben de Groot <yngwin@gentoo.org>:
>>> 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.
>
> Ugh. Firstly versionator is a piece of bloated crap that should have died a
> long time ago; all it does is stop Gentoo newbs learning the basics[1] of
> their implementation language, which leaves them open to nonsensical
> arguments about printf -v (glad you finally learnt that one, btw.)

Yes, it should have died a long time ago, that's why we're talking
about adding equivalent built-in functionality.  Please try to keep
up.  (And it's always amusing to see your bizarre delusions about what
I do and don't know.)

> Secondly, please explain fully and clearly, but concisely, why we can't
> simply state that EAPI=NN allows the ebuild to use the EAPI functions in
> global scope.

Because by the time the package manager knows the EAPI and is in a
position to provide the appropriate functions, the ebuild will have
already tried to use them.

> Bear in mind that you have to deal with the case of the mangler which can
> get EAPI from an ebuild without sourcing, as portage currently can, I
> believe.

Interesting....

> Relaxing that restriction strikes me as much saner than relaxing all the
> other restrictions which make interoperability easier.
>
> (Frankly, I'm amazed at having to state that to people trusted to write a
> specification. Follow up to -project on this point please, as it's about
> process, not technique.)

You're amazed that people trusted to write a specification don't
already know what "strikes you as much saner"?  Believe it or not, the
world does not revolve around you and your opinions.

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

[gentoo-dev] Re: GLEP 55 updated

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 817 bytes --]

On Sun, 17 May 2009 17:56:06 +0200
Piotr Jaroszyński <peper@gentoo.org> 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
> 
> I can live with any of these if that's what it takes to move forward.

I'd like 2 if we could have multiple same-versioned ebuilds of different
EAPI.  3 is good enough for me.

-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: GLEP 55 updated

[Piotr Jaroszyński]

2009/5/17 Ryan Hill <dirtyepic@gentoo.org>:
> On Sun, 17 May 2009 17:56:06 +0200
> Piotr Jaroszyński <peper@gentoo.org> 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
>>
>> I can live with any of these if that's what it takes to move forward.
>
> I'd like 2 if we could have multiple same-versioned ebuilds of different
> EAPI.  3 is good enough for me.

That's covered in the GLEP:

"Note that it is still not permitted to have more than one ebuild with
equal category, package name, and version. Although it would have the
advantage of allowing authors to provide backwards compatible ebuilds,
it would introduce problems too. The first is the requirement to have
strict EAPI ordering, the second is ensuring that all the ebuilds for
a single category/package-version are equivalent, i.e. installing any
of them has exactly the same effect on a given system."

I don't see a way to overcome these problems in a sensible way.

-- 
Best Regards,
Piotr Jaroszyński

Re: [gentoo-dev] Re: GLEP 55 updated

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

On Sun, 17 May 2009 12:15:24 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:
> I'd like 2 if we could have multiple same-versioned ebuilds of
> different EAPI.  3 is good enough for me.

We couldn't. Allowing multiple equal but different ebuilds gets highly
crazy -- EAPIs aren't orderable, so it's not obvious which one the
package manager should select.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: GLEP 55 updated

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 744 bytes --]

On Sun, 17 May 2009 19:18:14 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Sun, 17 May 2009 12:15:24 -0600
> Ryan Hill <dirtyepic@gentoo.org> wrote:
> > I'd like 2 if we could have multiple same-versioned ebuilds of
> > different EAPI.  3 is good enough for me.
> 
> We couldn't. Allowing multiple equal but different ebuilds gets highly
> crazy -- EAPIs aren't orderable, so it's not obvious which one the
> package manager should select.

Ah, right.  I knew there was a reason.


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] GLEP 55 updated

[Thomas de Grenier de Latour]

Hi,

On 2009/05/17, Piotr Jaroszyński <peper@gentoo.org> 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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

On Sun, 17 May 2009 20:40:37 +0200
Thomas de Grenier de Latour <tom.gl@free.fr> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] GLEP 55 updated

[Thomas de Grenier de Latour]

On 2009/05/17, Ciaran McCreesh <ciaran.mccreesh@googlemail.com> 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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2122 bytes --]

On Sun, 17 May 2009 21:57:40 +0200
Thomas de Grenier de Latour <tom.gl@free.fr> wrote:
> On 2009/05/17, Ciaran McCreesh <ciaran.mccreesh@googlemail.com> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] GLEP 55 updated

[Robert Buchholz]

[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] GLEP 55 updated

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: text/plain, Size: 632 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] GLEP 55 updated

[Piotr Jaroszyński]

2009/5/17 Robert Buchholz <rbu@gentoo.org>:
> 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

[gentoo-dev] Re: GLEP 55 updated

[Piotr Jaroszyński]

Just a heads up that I wrote a more detailed description of the
peformance hit that EAPI in the ebuild introduces.

Might come up with some numbers later too.

[1] - http://dev.gentoo.org/~peper/glep-0055.html#easily-fetchable-eapi-inside-the-ebuild

-- 
Best Regards,
Piotr Jaroszyński