Re: [gentoo-dev] EAPI-2

2008-09-12 Thread Michael Hammer
Hi folks!

I am not involved in creating the EAPI 2 draft but I am interested in
the discussion and would like to track the technical evolution but
this seams nearly impossible as you're not able to agree on a public
draft document.

* Ciaran McCreesh [EMAIL PROTECTED] [080911 20:02]:
 On Mon, 08 Sep 2008 23:34:28 +
 Jorge Manuel B. S. Vicetto [EMAIL PROTECTED] wrote:
  Given the earlier discussion about EAPI-2 in
  http://archives.gentoo.org/gentoo-dev/msg_3e9d42191c3537c4f699c12cadd0ad99.xml
  and cardoe's earlier request to the council ml, can the council
  members discuss this proposal and consider voting it?
  Does anyone have any objections to this proposal?
 
 I've prepared patches for PMS for this lot. They can be found on the
 branch 'eapi-2' at git://git.overlays.gentoo.org/proj/pms.git . Can we
 use these as the definitive definition?

So my request to the council is not a technical decision on the
content itself but at least a decision about which document is the
official draft.

So here are my suggestions: (which are an enhancement over the GLEP
process)

- An official (by the council accepted) VCS repo (a la git) for the
  document (EAPI draft or even the PMS spec?)

- An interface (mailing address) where everyone interested can submit
  a patch for this document and a herd which is responsible for
  maintaining and merging the patches if accepted. (- we need a
  procedure especially for the accept of patches. Voting, council
  decision, herd decision)

- A project page where the patches are published (and evtl. can be
  voted) and the HEAD is public readable

- The technical discussion can then be made in mailing list but then
  every dev has a possibility to follow the technical issues in a
  concentrated way and we have a place where we can cite and ref to.

- To make this work any other document or source for drafts has to be
  declined and not discussed (this seams hard but is IMHO the only way
  to make things work)

So long and thx for all the fish,

mueli

p.S.: If I missed something and something I mentioned already exists
then please correct me or forget my request but please be also so kind
and publish in a documentation (perhaps somewhere at [1]) where to
find informations on the EAPI process.

[1] ... http://www.gentoo.org/doc/en/list.xml

-- 

Michael Hammer|[EMAIL PROTECTED] | Graz, AT
Geno's Developer (Kerberos)  |  http://www.michael-hammer.at
 LocalWords:  Kerberos


pgphDTBmqsuAe.pgp
Description: PGP signature


Re: [gentoo-dev] EAPI-2

2008-09-12 Thread Ciaran McCreesh
On Fri, 12 Sep 2008 08:28:52 +0200
Michael Hammer [EMAIL PROTECTED] wrote:
 - An official (by the council accepted) VCS repo (a la git) for the
   document (EAPI draft or even the PMS spec?)

Uh, already exists.

 - An interface (mailing address) where everyone interested can submit
   a patch for this document and a herd which is responsible for
   maintaining and merging the patches if accepted. (- we need a
   procedure especially for the accept of patches. Voting, council
   decision, herd decision)

Already exists.

 - A project page where the patches are published (and evtl. can be
   voted) and the HEAD is public readable

Already exists.

 - The technical discussion can then be made in mailing list but then
   every dev has a possibility to follow the technical issues in a
   concentrated way and we have a place where we can cite and ref to.

Already happens.

 p.S.: If I missed something and something I mentioned already exists
 then please correct me or forget my request but please be also so kind
 and publish in a documentation (perhaps somewhere at [1]) where to
 find informations on the EAPI process.

How much research did you do before sending your email? Did you read
EAPI and PMS for people who haven't been paying attention?

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

2008-09-12 Thread Arun Raghavan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Donnie Berkholz wrote:
 On 12:46 Sun 07 Sep , Marcus D. Hanwell wrote:
 I personally agree with several others who have replied to this thread.  
 The reduction in lines of code/characters seems to introduce an uglier  
 syntax which is harder to read with questionable benefits.
 
 One of the great things about ebuilds is that they're very natural to 
 write in most cases, if you can manage to build the program by hand. 
 Raising this barrier of entry for questionable benefit seems like a bad 
 idea. We don't need to make it any harder to begin contributing to 
 Gentoo.

+42

- -- Arun
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjKqLgACgkQ+Vqt1inD4uwD9ACfXJSvMQ2Xsj+IlXz9F3QrgKiC
dSMAoKEPhM1KlL35fE7uxc6DZHegzIcW
=qTCS
-END PGP SIGNATURE-



[gentoo-dev] RFC: Glep 55 use case: moving slot to file name

2008-09-12 Thread Petteri Räty
Icedtea has two release tracks. One for the 1.7 OpenJDK code base and 
one for the 1.6 code base. They have independent version numbering so 
they can have collisions. By moving the slot to the file name we could 
have icedtea-1.2:1.6.ebuildN and icedtea-1.2:1.7.ebuildN. This 
particular situation can be worked around of course but it might also be 
better to keep the slot in the file name any way because I often find 
myself needing to know the slot of an ebuild (adjutrix -k of course 
already does this for me quite nicely).


Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] EAPI-2

2008-09-12 Thread Jim Ramsay
Ciaran McCreesh [EMAIL PROTECTED] wrote:
 On Tue, 9 Sep 2008 22:14:57 -0400
 Jim Ramsay [EMAIL PROTECTED] wrote:
  I was personally expecting to see some sort of section called
  EAPI-1 that contains something like:
  
  EAPI-1 consists of EAPI-0 with the following features added...
 
 Have a look at the eapi-differences-summary branch on
 git://git.overlays.gentoo.org/proj/pms.git . Is that roughly what
 you're after?

From what I could make out of the raw latex code, yes!

Unrelated topic:  What packages are actually required to 'make pms.pdf'
so I can actually read it?  I get:

! LaTeX Error: File `appendix.sty' not found.

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm)


signature.asc
Description: PGP signature


Re: [gentoo-dev] EAPI-2

2008-09-12 Thread Ciaran McCreesh
On Fri, 12 Sep 2008 14:14:51 -0400
Jim Ramsay [EMAIL PROTECTED] wrote:
 Unrelated topic:  What packages are actually required to 'make
 pms.pdf' so I can actually read it?  I get:

Have a look at the dependencies for app-doc/pms.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] RFC: Glep 55 use case: moving slot to file name

2008-09-12 Thread Ciaran McCreesh
On Fri, 12 Sep 2008 21:12:30 +0300
Petteri Räty [EMAIL PROTECTED] wrote:
 Icedtea has two release tracks. One for the 1.7 OpenJDK code base and 
 one for the 1.6 code base. They have independent version numbering so 
 they can have collisions. By moving the slot to the file name we
 could have icedtea-1.2:1.6.ebuildN and icedtea-1.2:1.7.ebuildN. This 
 particular situation can be worked around of course but it might also
 be better to keep the slot in the file name any way because I often
 find myself needing to know the slot of an ebuild (adjutrix -k of
 course already does this for me quite nicely).

Allowing multiple slots per version would require significant VDB
changes. Unfortunately we're still stuck with using VDB as-is whilst
EAPIs 0, 1 or 2 hang around...

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] RFC: Glep 55 use case: moving slot to file name

2008-09-12 Thread Donnie Berkholz
On 14:56 Fri 12 Sep , Doug Goldstein wrote:
 Petteri Räty wrote:
  Icedtea has two release tracks. One for the 1.7 OpenJDK code base and
  one for the 1.6 code base. They have independent version numbering so
  they can have collisions. By moving the slot to the file name we could
  have icedtea-1.2:1.6.ebuildN and icedtea-1.2:1.7.ebuildN. This
  particular situation can be worked around of course but it might also
  be better to keep the slot in the file name any way because I often
  find myself needing to know the slot of an ebuild (adjutrix -k of
  course already does this for me quite nicely).
 
  Regards,
  Petteri
 
 What's wrong with icedtea17-1.2 and icedtea16-1.2, because if its two
 different code bases that come up with two different tarballs that could
 be versioned differently or same that is the definition of a different
 package.

Have you considered reordering the versions it slightly, like this?

  icedtea-1.7.${version} (SLOT=1.7)
  icedtea-1.6.${version} (SLOT=1.6)

This allows you to keep it in the same package name and thus be more 
similar to how upstream handles it. The SLOT still allows for useful 
dependencies, and people installing any icedtea will automatically get 
the newest one without having to somehow choose which of multiple 
package names is right.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com


pgpV3rntfApq0.pgp
Description: PGP signature


Re: [gentoo-dev] RFC: Glep 55 use case: moving slot to file name

2008-09-12 Thread Petteri Räty

Donnie Berkholz kirjoitti:

On 14:56 Fri 12 Sep , Doug Goldstein wrote:

Petteri Räty wrote:

Icedtea has two release tracks. One for the 1.7 OpenJDK code base and
one for the 1.6 code base. They have independent version numbering so
they can have collisions. By moving the slot to the file name we could
have icedtea-1.2:1.6.ebuildN and icedtea-1.2:1.7.ebuildN. This
particular situation can be worked around of course but it might also
be better to keep the slot in the file name any way because I often
find myself needing to know the slot of an ebuild (adjutrix -k of
course already does this for me quite nicely).

Regards,
Petteri


What's wrong with icedtea17-1.2 and icedtea16-1.2, because if its two
different code bases that come up with two different tarballs that could
be versioned differently or same that is the definition of a different
package.


Have you considered reordering the versions it slightly, like this?

  icedtea-1.7.${version} (SLOT=1.7)
  icedtea-1.6.${version} (SLOT=1.6)

This allows you to keep it in the same package name and thus be more 
similar to how upstream handles it. The SLOT still allows for useful 
dependencies, and people installing any icedtea will automatically get 
the newest one without having to somehow choose which of multiple 
package names is right.




I do know how to get around it, I did state that in my original email. 
As it happens we are having a discussion on gentoo-java mailing list on 
whether we should use icedtea-openjdk build.icedtea version.ebuild 
or have different packages for the different slots. One of the upstream 
authors argues for the icedtea6 approach but to me it seems a bit 
Debianish but I agree with him on that 6.09.1.2 is not that clean either.


Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: Glep 55 use case: moving slot to file name

2008-09-12 Thread Donnie Berkholz
On 22:21 Fri 12 Sep , Petteri Räty wrote:
 I do know how to get around it, I did state that in my original email.  
 As it happens we are having a discussion on gentoo-java mailing list on  
 whether we should use icedtea-openjdk build.icedtea version.ebuild  
 or have different packages for the different slots. One of the upstream  
 authors argues for the icedtea6 approach but to me it seems a bit  
 Debianish but I agree with him on that 6.09.1.2 is not that clean either.

I also agree that it's not clean. Perhaps you could encourage your 
friendly upstream developers to have a versioning system that doesn't 
suck?

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com


pgpjiTNfarWGJ.pgp
Description: PGP signature


Re: [gentoo-dev] RFC: Glep 55 use case: moving slot to file name

2008-09-12 Thread Petteri Räty

Donnie Berkholz kirjoitti:

On 22:21 Fri 12 Sep , Petteri Räty wrote:
I do know how to get around it, I did state that in my original email.  
As it happens we are having a discussion on gentoo-java mailing list on  
whether we should use icedtea-openjdk build.icedtea version.ebuild  
or have different packages for the different slots. One of the upstream  
authors argues for the icedtea6 approach but to me it seems a bit  
Debianish but I agree with him on that 6.09.1.2 is not that clean either.


I also agree that it's not clean. Perhaps you could encourage your 
friendly upstream developers to have a versioning system that doesn't 
suck?




Well if we strictly follow upstream naming and versioning then we don't 
need the two part version numbers but end up with packages named icedtea 
and icedtea6.


Regards,
Petteri



signature.asc
Description: OpenPGP digital signature