GLEP 55 updated

classic Classic list List threaded Threaded
55 messages Options
123
Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

Re: GLEP 55 updated

Peter Alfredsen-3
On Sun, 17 May 2009 17:56:06 +0200
Piotr Jaroszyński <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: GLEP 55 updated

Denis Dupeyron
In reply to this post by Piotr Jaroszyński
2009/5/17 Piotr Jaroszyński <[hidden email]>:
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: GLEP 55 updated

Ulrich Mueller-2
>>>>> On Sun, 17 May 2009, Denis Dupeyron wrote:

> 2009/5/17 Piotr Jaroszyñski <[hidden email]>:

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

Reply | Threaded
Open this post in threaded view
|

Re: GLEP 55 updated

Nirbheek Chauhan-2
In reply to this post by Peter Alfredsen-3
On Sun, May 17, 2009 at 9:36 PM, Peter Alfredsen <[hidden email]> wrote:
> On Sun, 17 May 2009 17:56:06 +0200
> Piotr Jaroszyński <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: GLEP 55 updated

Joe Peterson-3
In reply to this post by Denis Dupeyron
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

Reply | Threaded
Open this post in threaded view
|

Re: GLEP 55 updated

Jorge Manuel B. S. Vicetto-2
In reply to this post by Ulrich Mueller-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ulrich Mueller wrote:

>>>>>> On Sun, 17 May 2009, Denis Dupeyron wrote:
>
>> 2009/5/17 Piotr Jaroszyñski <[hidden email]>:
>
>>> 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-----

Reply | Threaded
Open this post in threaded view
|

Re: GLEP 55 updated

Markos Chandras-2
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 <[hidden email]>:
> >>> 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 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GLEP 55 updated

Joe Peterson-3
In reply to this post by Jorge Manuel B. S. Vicetto-2
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

Reply | Threaded
Open this post in threaded view
|

Re: GLEP 55 updated

Ryan Hill-3
In reply to this post by Piotr Jaroszyński
On Sun, 17 May 2009 17:56:06 +0200
Piotr Jaroszyński <[hidden email]> 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

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: GLEP 55 updated

Piotr Jaroszyński
2009/5/17 Ryan Hill <[hidden email]>:

> On Sun, 17 May 2009 17:56:06 +0200
> Piotr Jaroszyński <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Re: GLEP 55 updated

Ciaran McCreesh-4
In reply to this post by Ryan Hill-3
On Sun, 17 May 2009 12:15:24 -0600
Ryan Hill <[hidden email]> 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

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GLEP 55 updated

Thomas de Grenier de Latour-2
In reply to this post by Piotr Jaroszyński
Hi,

On 2009/05/17, Piotr Jaroszyński <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: GLEP 55 updated

Ciaran McCreesh-4
On Sun, 17 May 2009 20:40:37 +0200
Thomas de Grenier de Latour <[hidden email]> 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 (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GLEP 55 updated

Peter Alfredsen-3
In reply to this post by Nirbheek Chauhan-2
On Sun, 17 May 2009 22:54:38 +0530
Nirbheek Chauhan <[hidden email]> wrote:

> On Sun, May 17, 2009 at 9:36 PM, Peter Alfredsen
> <[hidden email]> wrote:
> > On Sun, 17 May 2009 17:56:06 +0200
> > Piotr Jaroszyński <[hidden email]> 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

rbu
Reply | Threaded
Open this post in threaded view
|

Re: GLEP 55 updated

rbu
In reply to this post by Piotr Jaroszyński
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 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GLEP 55 updated

Ryan Hill-3
In reply to this post by Ciaran McCreesh-4
On Sun, 17 May 2009 19:18:14 +0100
Ciaran McCreesh <[hidden email]> wrote:

> On Sun, 17 May 2009 12:15:24 -0600
> Ryan Hill <[hidden email]> 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

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GLEP 55 updated

Piotr Jaroszyński
In reply to this post by 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

Reply | Threaded
Open this post in threaded view
|

Re: GLEP 55 updated

Arfrever Frehtes Taifersar Arahesis-3
In reply to this post by rbu
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 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GLEP 55 updated

Piotr Jaroszyński
In reply to this post by rbu
2009/5/17 Robert Buchholz <[hidden email]>:

> 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

123