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
