Re: [gentoo-dev] EAPI-2
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
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
-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
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
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
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
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
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
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
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
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
