Hi,
A whole bunch of people helped write the Java packaging guidelines draft currently on the wiki:
http://fedoraproject.org/wiki/PackagingDrafts/Java
All of the questions and comments and TODOs that were on the page have been taken care of. I'm sure there are going to be questions and complaints, but we now feel it's in a state worthy of first draft presentation.
I've added it to the agenda for the next FPC meeting, but discussion before then may help get issues dealt with.
Note that we've moved the section on Java webapps to a separate page as we (myself and Tom Fitzsimmons) feel it is too involved of a section to include in the Java guidelines themselves. Some also feel it should be considered in light of general guidelines for web applications. It's been moved here:
http://fedoraproject.org/wiki/PackagingDrafts/JavaWebApps
Thanks go to Tom Fitzsimmons, Matt Wringe, David Walluck, Permaine Cheung, Deepak Bhole, Lillian Angel, Nicolas Mailhot, Ville Skyttä, Jason Tibbets, Lubomir Kundrak, Hans de Goede, Colin Walters, Fernando Nasser, Gary Benson, Andrew Haley, and others who I'm forgetting.
Andrew
On Tue, 2008-03-25 at 16:36 -0400, Andrew Overholt wrote:
Hi,
A whole bunch of people helped write the Java packaging guidelines draft currently on the wiki:
http://fedoraproject.org/wiki/PackagingDrafts/Java
All of the questions and comments and TODOs that were on the page have been taken care of. I'm sure there are going to be questions and complaints, but we now feel it's in a state worthy of first draft presentation.
Thanks to everyone who did work on this. And now, for my comments:
1. The JPackageNaming exception needs to die. It was a painful compromise originally, and now, it just needs to be removed. I will vote -1 on any draft that contains it, unless someone comes up with a much more convincing rationale for its continued existence.
2. "The JPackage Project has defined standard file system locations and conventions for use in Java packages. Many distributions have inherited these conventions and in the vast majority of cases, Fedora follows them verbatim. We include relevant sections of the JPackage guidelines here but caution that the canonical document will always reside upstream: JPackage Guidelines "
I'm not sure what this section is intended to provide. It seems to imply that the JPackage Guidelines are the real guidelines, in which case, what point do the Fedora Guidelines serve? I have no problem giving the JPackage team credit for the origination of many of the Fedora Guidelines, but to refer to that as "the canonical document" is wrong. This is supposed to be the canonical document for Fedora Java Guidelines.
I'd prefer to see this entire section replaced with:
The Fedora Java Guidelines are based on guidelines originally drafted by the JPackage Project.
3. "If the number of provided JAR files exceeds two, place them into a sub-directory." What makes two the magic number here? Why not simply more than 1?
4. "Java packages in Fedora should enumerate their dependencies with Requires." I think this might need to be a "must", not just a "should".
5. I would like to see a section reminding people that all Java packages MUST be built from source code, and that pre-built binary files (JARs or otherwise) are not acceptable. The "Pre-built JAR files / Other bundled software" is probably intended to do this, but it uses a lot of "shoulds", and never explicitly states that this must not happen.
6. Please add an example of how to resolve class-path-in-manifest issues.
7. Go through the entire document and make sure that you're using "must" and "should" appropriately. "Should" means that you are not required to do it, its just a good idea. "Must" means that you are required to do it, and that it will fail a package on review. For example, the "Javadoc scriptlets" seems like it is a "must" not a "should".
8. "%{_jnidir} usually expands into /usr/lib/java." This should probably be %{_libdir}/java.
9. I think you've got an accidental line wrap in the example for "Packaging JAR files that use JNI"
10. It might also be worthwhile to do an "ant" spec template and a "maven" spec template. I'm not sure how different these two packaging types would be, but the guidelines seem to imply significant differences.
~spot
Tom "spot" Callaway wrote:
On Tue, 2008-03-25 at 16:36 -0400, Andrew Overholt wrote:
Hi,
A whole bunch of people helped write the Java packaging guidelines draft currently on the wiki:
http://fedoraproject.org/wiki/PackagingDrafts/Java
All of the questions and comments and TODOs that were on the page have been taken care of. I'm sure there are going to be questions and complaints, but we now feel it's in a state worthy of first draft presentation.
Thanks to everyone who did work on this. And now, for my comments:
Yes, many thanks to all involved!
- The JPackageNaming exception needs to die. It was a painful
compromise originally, and now, it just needs to be removed. I will vote -1 on any draft that contains it, unless someone comes up with a much more convincing rationale for its continued existence.
? Can someone explain to me what is meant with JPackageNaming?
- "The JPackage Project has defined standard file system locations and
conventions for use in Java packages. Many distributions have inherited these conventions and in the vast majority of cases, Fedora follows them verbatim. We include relevant sections of the JPackage guidelines here but caution that the canonical document will always reside upstream: JPackage Guidelines "
I'm not sure what this section is intended to provide. It seems to imply that the JPackage Guidelines are the real guidelines, in which case, what point do the Fedora Guidelines serve? I have no problem giving the JPackage team credit for the origination of many of the Fedora Guidelines, but to refer to that as "the canonical document" is wrong. This is supposed to be the canonical document for Fedora Java Guidelines.
I'd prefer to see this entire section replaced with:
The Fedora Java Guidelines are based on guidelines originally drafted by the JPackage Project.
+1
- "If the number of provided JAR files exceeds two, place them into a
sub-directory." What makes two the magic number here? Why not simply more than 1?
+1
- "Java packages in Fedora should enumerate their dependencies with
Requires." I think this might need to be a "must", not just a "should".
+1, any needed jars (or rather there containing packages) which are not part of the jre should be required.
- I would like to see a section reminding people that all Java packages
MUST be built from source code, and that pre-built binary files (JARs or otherwise) are not acceptable. The "Pre-built JAR files / Other bundled software" is probably intended to do this, but it uses a lot of "shoulds", and never explicitly states that this must not happen.
+1
- Please add an example of how to resolve class-path-in-manifest
issues.
+1
- Go through the entire document and make sure that you're using "must"
and "should" appropriately. "Should" means that you are not required to do it, its just a good idea. "Must" means that you are required to do it, and that it will fail a package on review. For example, the "Javadoc scriptlets" seems like it is a "must" not a "should".
+1
- "%{_jnidir} usually expands into /usr/lib/java." This should probably
be %{_libdir}/java.
Yes it should are rather must :) be %{_libdir}/java
Regards,
Hans
On Tue, 2008-03-25 at 22:13 +0100, Hans de Goede wrote:
? Can someone explain to me what is meant with JPackageNaming?
All of the packages which originated from the JPackage repository had a "repotag" of jpp on them. When they were merged into Fedora Core (pre-Core/Extras merge), they kept their jpp repotag. When the merger happened, we tried to get rid of the repotag, because it was a violation of the NamingGuidelines, but we got a huge amount of pushback on this.
Finally, simply to get past the issue, we drafted a temporary compromise, letting the repotag remain until it was no longer useful. The intent was to provide some time for the Java packagers to work out alternate methods to perform the tasks that they were reliant upon the repotag for... but no such work ever took place.
In fact, upon retrospection, I'm not entirely sure what value the repotag holds, which is why it either needs to be thoroughly rationalized, or gotten rid of entirely.
~spot
On Tue, Mar 25, 2008 at 05:19:24PM -0400, Tom spot Callaway wrote:
On Tue, 2008-03-25 at 22:13 +0100, Hans de Goede wrote:
? Can someone explain to me what is meant with JPackageNaming?
All of the packages which originated from the JPackage repository had a "repotag" of jpp on them. When they were merged into Fedora Core (pre-Core/Extras merge), they kept their jpp repotag. When the merger happened, we tried to get rid of the repotag, because it was a violation of the NamingGuidelines, but we got a huge amount of pushback on this.
Finally, simply to get past the issue, we drafted a temporary compromise, letting the repotag remain until it was no longer useful. The intent was to provide some time for the Java packagers to work out alternate methods to perform the tasks that they were reliant upon the repotag for... but no such work ever took place.
In fact, upon retrospection, I'm not entirely sure what value the repotag holds, which is why it either needs to be thoroughly rationalized, or gotten rid of entirely.
The idea was to treat jpackage as an upstream vendor such that Fedora imports jpackage rpms, does some modifications on them, but still the next jpackage release would win over the "local" Fedora modifications.
The same argument that undoes jpackage's guidelines as canonical over Fedora's applied here would mean that this setup is no longer wanted anymore.
W/o being involved in jpackage I kinda liked their cross-distribution type of work. Perhaps the Fedora java guidelines could flow back into jpackage's. After all there are many jpackage folks around here.
On Tue, 2008-03-25 at 23:49 +0200, Axel Thimm wrote:
W/o being involved in jpackage I kinda liked their cross-distribution type of work. Perhaps the Fedora java guidelines could flow back into jpackage's. After all there are many jpackage folks around here.
The conference call I was on with jpackage and RH and Fedora folks last week seemed to assume that the Fedora Packaging Guidelines would service /as/ the Jpackage guidelines, period.
* Jesse Keating jkeating@redhat.com [2008-03-25 21:08]:
On Tue, 2008-03-25 at 23:49 +0200, Axel Thimm wrote:
W/o being involved in jpackage I kinda liked their cross-distribution type of work. Perhaps the Fedora java guidelines could flow back into jpackage's. After all there are many jpackage folks around here.
The conference call I was on with jpackage and RH and Fedora folks last week seemed to assume that the Fedora Packaging Guidelines would service /as/ the Jpackage guidelines, period.
I don't recall that. It was discussed that we'd like to deviate as little as possible from JPackage conventions and work with them to get critical changes we need accepted there.
Andrew
On Tue, 2008-03-25 at 21:43 -0400, Andrew Overholt wrote:
I don't recall that. It was discussed that we'd like to deviate as little as possible from JPackage conventions and work with them to get critical changes we need accepted there.
Ok, I've made a bad assumption.
What is preventing the Fedora guidelines from becoming the jpackage guidelines?
Le Mer 26 mars 2008 03:00, Jesse Keating a écrit :
On Tue, 2008-03-25 at 21:43 -0400, Andrew Overholt wrote:
I don't recall that. It was discussed that we'd like to deviate as little as possible from JPackage conventions and work with them to get critical changes we need accepted there.
Ok, I've made a bad assumption.
What is preventing the Fedora guidelines from becoming the jpackage guidelines?
JPackage is a cross-distribution neutral ground. So its guidelines can not be approved only at the Fedora level without alienating non-Fedora JPP contributors. JPackage Fedora members can propose Fedora-oriented changes, and those changes can be then adopted as-is by the project (if other JPP players have no objection), but I don't think something Fedora-branded, Fedora-hosted, and with only FPC or FESCO control is going to fly.
On Wed, 2008-03-26 at 11:28 +0100, Nicolas Mailhot wrote:
JPackage is a cross-distribution neutral ground. So its guidelines can not be approved only at the Fedora level without alienating non-Fedora JPP contributors. JPackage Fedora members can propose Fedora-oriented changes, and those changes can be then adopted as-is by the project (if other JPP players have no objection), but I don't think something Fedora-branded, Fedora-hosted, and with only FPC or FESCO control is going to fly.
Ok, I can see where that's coming from, but at this time, what are the guideline differences? Surely the "JPP" guidelines could just be a set of temporary exceptions from the Fedora guidelines until such time as they get rolled into the Fedora guidelines? JPackage wouldn't be the only ones making use of Fedora as an upstream for guidelines. I do believe multiple other distros are using our licensing guidelines either directly or as a cut/paste job.
Le Mer 26 mars 2008 12:29, Jesse Keating a écrit :
Surely the "JPP" guidelines could just be a set of temporary exceptions from the Fedora guidelines until such time as they get rolled into the Fedora guidelines? JPackage wouldn't be the only ones making use of Fedora as an upstream for guidelines.
Other distributions also have guideline ambitions so this is definitely not going to fly. It's very wrong to think JPP only looks at Fedora as guideline source and other distros are doing nothing in the meanwhile.
On Wed, 2008-03-26 at 12:48 +0100, Nicolas Mailhot wrote:
Le Mer 26 mars 2008 12:29, Jesse Keating a écrit :
Surely the "JPP" guidelines could just be a set of temporary exceptions from the Fedora guidelines until such time as they get rolled into the Fedora guidelines? JPackage wouldn't be the only ones making use of Fedora as an upstream for guidelines.
Other distributions also have guideline ambitions so this is definitely not going to fly. It's very wrong to think JPP only looks at Fedora as guideline source and other distros are doing nothing in the meanwhile.
Can we see some examples instead of just vague threats of "not going to fly" ?
Le Mer 26 mars 2008 13:50, Jesse Keating a écrit :
On Wed, 2008-03-26 at 12:48 +0100, Nicolas Mailhot wrote:
Le Mer 26 mars 2008 12:29, Jesse Keating a écrit :
Surely the "JPP" guidelines could just be a set of temporary exceptions from the Fedora guidelines until such time
as
they get rolled into the Fedora guidelines? JPackage wouldn't be
the
only ones making use of Fedora as an upstream for guidelines.
Other distributions also have guideline ambitions so this is definitely not going to fly. It's very wrong to think JPP only looks at Fedora as guideline source and other distros are doing nothing in the meanwhile.
Can we see some examples instead of just vague threats of "not going to fly" ?
Sure
http://wiki.mandriva.com/en/Policies/Java/JPackage/skel.spec http://wiki.mandriva.com/en/Policies/Java/JPackage
On Wed, 2008-03-26 at 16:31 +0100, Nicolas Mailhot wrote:
Sure
http://wiki.mandriva.com/en/Policies/Java/JPackage/skel.spec http://wiki.mandriva.com/en/Policies/Java/JPackage
Gee, seems like they're trying to solve all the same problems with jpackage that we are. I'm sensing a trend...
While overuse of macros may at times be ugly, those usages seem to be a common desire both in Fedora and Mandirva to deal with jpackage packages.
If all the distros are making guidelines to cope with the shortcommings of jpackage packages, why can't we just fix the jpackage packages?
Le Mer 26 mars 2008 16:41, Jesse Keating a écrit :
On Wed, 2008-03-26 at 16:31 +0100, Nicolas Mailhot wrote:
Sure
http://wiki.mandriva.com/en/Policies/Java/JPackage/skel.spec http://wiki.mandriva.com/en/Policies/Java/JPackage
Gee, seems like they're trying to solve all the same problems with jpackage that we are. I'm sensing a trend...
While overuse of macros may at times be ugly, those usages seem to be a common desire both in Fedora and Mandirva to deal with jpackage packages.
If all the distros are making guidelines to cope with the shortcommings of jpackage packages, why can't we just fix the jpackage packages?
Because all the distro guideline guys want to work inside their own personal guideline committee instead of meeting each other at the project level where they have less control. Which can't work as long as the project is shared.
If you want it to work either have everyone involved CC the messages to the jpackage-discuss mailing list or delegate someone from FPC to work there.
On Wed, 2008-03-26 at 16:57 +0100, Nicolas Mailhot wrote:
Because all the distro guideline guys want to work inside their own personal guideline committee instead of meeting each other at the project level where they have less control. Which can't work as long as the project is shared.
Well, we have this new freedesktop.org mailing list for cross-distro cooperation. Sounds like a great place to bring such discussions.
If you want it to work either have everyone involved CC the messages to the jpackage-discuss mailing list or delegate someone from FPC to work there.
Well I'm no longer on FPC, but I wouldn't mind taking this up on the freedesktop list. Would somebody from jpackage who does packaging guidelines like to join said list? http://lists.freedesktop.org/mailman/listinfo/distributions
* Jesse Keating jkeating@redhat.com [2008-03-26 12:03]:
On Wed, 2008-03-26 at 16:57 +0100, Nicolas Mailhot wrote:
Because all the distro guideline guys want to work inside their own personal guideline committee instead of meeting each other at the project level where they have less control. Which can't work as long as the project is shared.
Well, we have this new freedesktop.org mailing list for cross-distro cooperation. Sounds like a great place to bring such discussions.
There's no need to move this to freedesktop.org since JPackage is already distro-neutral. Fixes should be made *with* JPackage (with their blessing and that of the other distros, of course).
Here's a potential way forward from Fedora's side:
1) get Fedora guidelines in order 2) distill divergences from JPackage 3) work with JPackage to deal with divergences thereby fixing other distros, etc.
I think we're well on the way towards solving 1) above. 2) will fall out of that and the many contributors to *both* Fedora and JPackage can take the changes and present them in JPackage forums and deal with 3).
Then we can deal with the actual hard problems of merging contributions/contributors, inter-leaving of repos, etc.
Andrew
Le Mer 26 mars 2008 16:57, Nicolas Mailhot a écrit :
Le Mer 26 mars 2008 16:41, Jesse Keating a écrit :
If all the distros are making guidelines to cope with the shortcommings of jpackage packages, why can't we just fix the jpackage packages?
Because all the distro guideline guys want to work inside their own personal guideline committee instead of meeting each other at the project level where they have less control. Which can't work as long as the project is shared.
If you want it to work either have everyone involved CC the messages to the jpackage-discuss mailing list or delegate someone from FPC to work there.
(Though to be honest the Mandriva guys did try. But they had no one representing FPC to talk to)
On Wednesday 26 March 2008, Nicolas Mailhot wrote:
Le Mer 26 mars 2008 16:57, Nicolas Mailhot a écrit :
If you want it to work either have everyone involved CC the messages to the jpackage-discuss mailing list or delegate someone from FPC to work there.
(Though to be honest the Mandriva guys did try. But they had no one representing FPC to talk to)
Hm, I'm both a FPC and a JPackage member. I haven't been active in JPackage for some time though (only following jpackage-admin and doing some rare package updates), maybe that's why I haven't heard/noticed anyone looking for such a contact.
Le mardi 25 mars 2008 à 17:06 -0400, Tom "spot" Callaway a écrit :
On Tue, 2008-03-25 at 16:36 -0400, Andrew Overholt wrote:
Hi,
A whole bunch of people helped write the Java packaging guidelines draft currently on the wiki:
http://fedoraproject.org/wiki/PackagingDrafts/Java
All of the questions and comments and TODOs that were on the page have been taken care of. I'm sure there are going to be questions and complaints, but we now feel it's in a state worthy of first draft presentation.
Thanks to everyone who did work on this. And now, for my comments:
- The JPackageNaming exception needs to die. It was a painful
compromise originally, and now, it just needs to be removed. I will vote -1 on any draft that contains it, unless someone comes up with a much more convincing rationale for its continued existence.
I don't see what changed since the discussion on JPackageNaming. The original arguments still stand, and no further element occurred to my knowledge to justify changing the compromise that was painfully achieved.
- "The JPackage Project has defined standard file system locations and
conventions for use in Java packages. Many distributions have inherited these conventions and in the vast majority of cases, Fedora follows them verbatim. We include relevant sections of the JPackage guidelines here but caution that the canonical document will always reside upstream: JPackage Guidelines "
I'm not sure what this section is intended to provide. It seems to imply that the JPackage Guidelines are the real guidelines, in which case, what point do the Fedora Guidelines serve? I have no problem giving the JPackage team credit for the origination of many of the Fedora Guidelines, but to refer to that as "the canonical document" is wrong. This is supposed to be the canonical document for Fedora Java Guidelines.
It's canonical in the sense it's an external document we respect, just like the FHS, the freedesktop.org specs, etc are external conventions we respect. Must each of those documents be parroted in our guidelines to indicate we follow them?
I'd prefer to see this entire section replaced with:
The Fedora Java Guidelines are based on guidelines originally drafted by the JPackage Project.
Fedora has a voice in having the JPP guidelines changes BTW should it be necessary. You don't need to pull them in Fedora to get some control.
- "If the number of provided JAR files exceeds two, place them into a
sub-directory." What makes two the magic number here? Why not simply more than 1?
When the JPP guidelines were written, a magic number was needed, and 2 was a reasonable choice given the composition of the jpp repo at the time (ie there were several heavily used packages with just 2 jars, and the pain of changing them was not worth it). It does not mean anything more than that.
- "%{_jnidir} usually expands into /usr/lib/java." This should probably
be %{_libdir}/java.
The original jpp tools scripts are not multilib-safe (I didn't have a x86_64 system available when I wrote them). When the problem was identified by people with the right hardware, a quickfix (proposed by RH IIRC) consisted in changing all the %{_libdir}s in the original guidelines with /usr/lib.
Since then no one took the time to make the scripts multilib-safe.
- It might also be worthwhile to do an "ant" spec template and a
"maven" spec template. I'm not sure how different these two packaging types would be, but the guidelines seem to imply significant differences.
I fear the ant case is likely to be quite un-representative. It would be like making a "make" case without the GNU project having imposed strong conventions on standard makefile targets.
"NM" == Nicolas Mailhot nicolas.mailhot@laposte.net writes:
NM> I don't see what changed since the discussion on NM> JPackageNaming
Actually a whole pile of stuff has changed then.
One of the action items from the conference call I attended recently was that Fernando would actually document the reasons why we needed (and, perhaps, still need) the jpp tag. If for no other reason than we'll actually know. One reason that I recall heading during the conference was the need to be able to easily query for all of the java packages on the system in some manner, and we have better query tools now (along with packagekit to abstract this kind of thing). Perhaps someone else who was on that call (Jesse?) can say whether I'm misremembering.
But it's certainly a reasonable time to revisit the issue, although it's going to be tough to discuss much without that documentation about the reasons for the tag.
- J<
On Tue, 2008-03-25 at 17:24 -0500, Jason L Tibbitts III wrote:
Actually a whole pile of stuff has changed then.
One of the action items from the conference call I attended recently was that Fernando would actually document the reasons why we needed (and, perhaps, still need) the jpp tag. If for no other reason than we'll actually know. One reason that I recall heading during the conference was the need to be able to easily query for all of the java packages on the system in some manner, and we have better query tools now (along with packagekit to abstract this kind of thing). Perhaps someone else who was on that call (Jesse?) can say whether I'm misremembering.
But it's certainly a reasonable time to revisit the issue, although it's going to be tough to discuss much without that documentation about the reasons for the tag.
You got it right Jason, thanks!
On Tue, 2008-03-25 at 23:03 +0100, Nicolas Mailhot wrote:
I don't see what changed since the discussion on JPackageNaming. The original arguments still stand, and no further element occurred to my knowledge to justify changing the compromise that was painfully achieved.
These reasons need to be actually enumerated somewhere, so that they can be re-examined with today's tools, and if today's tools aren't up to the task we can have a target to shoot for with tomorrow's tools. Thus far I have only seen hand wavy reasons as to why it's "needed" and no clear statements as to what problems are being solved with their existence.
* Jesse Keating jkeating@redhat.com [2008-03-25 21:10]:
On Tue, 2008-03-25 at 23:03 +0100, Nicolas Mailhot wrote:
I don't see what changed since the discussion on JPackageNaming. The original arguments still stand, and no further element occurred to my knowledge to justify changing the compromise that was painfully achieved.
These reasons need to be actually enumerated somewhere, so that they can be re-examined with today's tools, and if today's tools aren't up to the task we can have a target to shoot for with tomorrow's tools. Thus far I have only seen hand wavy reasons as to why it's "needed" and no clear statements as to what problems are being solved with their existence.
I emailed people's "action items" from our little meeting and that was on Fernano's plate. At the time he told me he was going to try to get to it yesterday so I'll ping him to find out the status.
Andrew
* Jesse Keating jkeating@redhat.com [2008-03-25 21:10]:
On Tue, 2008-03-25 at 23:03 +0100, Nicolas Mailhot wrote:
I don't see what changed since the discussion on JPackageNaming. The original arguments still stand, and no further element occurred to my knowledge to justify changing the compromise that was painfully achieved.
These reasons need to be actually enumerated somewhere, so that they can be re-examined with today's tools, and if today's tools aren't up to the task we can have a target to shoot for with tomorrow's tools. Thus far I have only seen hand wavy reasons as to why it's "needed" and no clear statements as to what problems are being solved with their existence.
An important reason we need the jpp in there currently is to maintain compatibility with JPackage.
With the way the naming is right now, users can enable a JPackage repository beside a Fedora repo, and are guaranteed to get the latest either from Fedora or JPackage, whichever is newer. Without the jpp in the release tag, this compatibility is broken. And it goes beyond the packages themselves -- it also affects dependent packages,
e.g package foo is currently at 1.0-1jpp in jpackage and 1.0-1jpp.1 in Fedora. If package bar depends on foo, and needs a fix to go into foo (1.0-2jpp), it can require foo >= 1.0-2 ... if fedora removed the "1jpp" from it's release tag, the next release of package foo in Fedora may satisfy bar's requirement, but won't work.
Fedora's Java package set is nowhere close to as big as JPackage's, and we should not break compatibility between Fedora and JPackage just for the sake of a clean looking release tag.
Deepak
On Thu, 2008-03-27 at 15:13 -0400, Deepak Bhole wrote:
An important reason we need the jpp in there currently is to maintain compatibility with JPackage.
We have never supported repository mixing. If anything, this serves as a good reason that JPackage should drop their disttag.
~spot
* Tom spot Callaway tcallawa@redhat.com [2008-03-27 15:25]:
On Thu, 2008-03-27 at 15:13 -0400, Deepak Bhole wrote:
An important reason we need the jpp in there currently is to maintain compatibility with JPackage.
We have never supported repository mixing. If anything, this serves as a good reason that JPackage should drop their disttag.
How many other repositories are there with the entire stack duplicated? (not being sarcastic.. I really don't know of any). I know that there were conflicts with Livna and what not a while ago, but those were for a handful of packages only.
As for JPackage dropping their release tag policy -- not to be the devil's advocate, but they were here before Fedora...
I have heard of numerous requests for technical arguments as to why the string is needed. But where the technical arguments as to why it should be removed? From what I have seen so far, reasons for that are pretty much "Because it looks better, because it a policy, etc."
Cheers, Deepak
On Thu, 2008-03-27 at 15:54 -0400, Deepak Bhole wrote:
- Tom spot Callaway tcallawa@redhat.com [2008-03-27 15:25]:
On Thu, 2008-03-27 at 15:13 -0400, Deepak Bhole wrote:
An important reason we need the jpp in there currently is to maintain compatibility with JPackage.
We have never supported repository mixing. If anything, this serves as a good reason that JPackage should drop their disttag.
How many other repositories are there with the entire stack duplicated? (not being sarcastic.. I really don't know of any). I know that there were conflicts with Livna and what not a while ago, but those were for a handful of packages only.
As for JPackage dropping their release tag policy -- not to be the devil's advocate, but they were here before Fedora...
I have heard of numerous requests for technical arguments as to why the string is needed. But where the technical arguments as to why it should be removed? From what I have seen so far, reasons for that are pretty much "Because it looks better, because it a policy, etc."
It causes rpm ordering to be painful. The Version and Release should be wholly numeric, whenever they aren't, rpm's ordering gets rather non-intuitive. We've defined special, strictly controlled cases when it is ok to have non-numeric characters in the version or release (especially release), but only when there is a real need.
So, again, where is the real need for tacking jpp on the end of Release?
~spot
* Tom spot Callaway tcallawa@redhat.com [2008-03-27 16:26]:
So, again, where is the real need for tacking jpp on the end of Release?
Fernando said he'd write up the reasons from the last time this argument was had.
Fernando: how are things going? Please post here when you've got a wiki page to share.
Andrew
* Tom spot Callaway tcallawa@redhat.com [2008-03-27 16:26]:
On Thu, 2008-03-27 at 15:54 -0400, Deepak Bhole wrote:
- Tom spot Callaway tcallawa@redhat.com [2008-03-27 15:25]:
On Thu, 2008-03-27 at 15:13 -0400, Deepak Bhole wrote:
An important reason we need the jpp in there currently is to maintain compatibility with JPackage.
We have never supported repository mixing. If anything, this serves as a good reason that JPackage should drop their disttag.
How many other repositories are there with the entire stack duplicated? (not being sarcastic.. I really don't know of any). I know that there were conflicts with Livna and what not a while ago, but those were for a handful of packages only.
As for JPackage dropping their release tag policy -- not to be the devil's advocate, but they were here before Fedora...
I have heard of numerous requests for technical arguments as to why the string is needed. But where the technical arguments as to why it should be removed? From what I have seen so far, reasons for that are pretty much "Because it looks better, because it a policy, etc."
It causes rpm ordering to be painful. The Version and Release should be wholly numeric, whenever they aren't, rpm's ordering gets rather non-intuitive. We've defined special, strictly controlled cases when it is ok to have non-numeric characters in the version or release (especially release), but only when there is a real need.
Okay, thanks for the clarification.
So, again, where is the real need for tacking jpp on the end of Release?
The need is compatibility with JPackage. Our Java stack is simply not big enough. Most of the Java packages in Fedora have gone in as direct and indirect dependencies of Eclipse and Maven. In other words, JPackage still has a large selection of directly usable Java apps.
*IF* we can convince JPackage to drop jpp, all would be fine. If we cannot -- are we willing to lose compatibility?
Btw, there is also middleground that I haven't seen being discussed: What if we drop the "jpp", but keep the X from Xjpp? So foo-1.0-1jpp becomes foo-1.0-1.1 in Fedora.
This would maintain compatibility, and would give us numeric releases.
The above compromise would cause us to lose the ability to gather a list of packages in the Java stack/common packages (with JPackage) though.
Deepak
On Thu, 2008-03-27 at 16:51 -0400, Deepak Bhole wrote:
Btw, there is also middleground that I haven't seen being discussed: What if we drop the "jpp", but keep the X from Xjpp? So foo-1.0-1jpp becomes foo-1.0-1.1 in Fedora.
This would maintain compatibility, and would give us numeric releases.
This is actually permitted with the current guidelines.
~spot
On Thu, 2008-03-27 at 17:00 -0400, Tom "spot" Callaway wrote:
Btw, there is also middleground that I haven't seen being discussed: What if we drop the "jpp", but keep the X from Xjpp? So foo-1.0-1jpp becomes foo-1.0-1.1 in Fedora.
This would maintain compatibility, and would give us numeric
releases.
This is actually permitted with the current guidelines.
Not only that, but it was one of the suggested methods to rid ourselves of jpp. I do believe I had a complete working scheme using just numbers that left Jpackage with the ability to have "rpm newer" packages than those in Fedora.
Deepak Bhole wrote:
- Tom spot Callaway tcallawa@redhat.com [2008-03-27 16:26]:
On Thu, 2008-03-27 at 15:54 -0400, Deepak Bhole wrote:
- Tom spot Callaway tcallawa@redhat.com [2008-03-27 15:25]:
On Thu, 2008-03-27 at 15:13 -0400, Deepak Bhole wrote:
An important reason we need the jpp in there currently is to maintain compatibility with JPackage.
We have never supported repository mixing. If anything, this serves as a good reason that JPackage should drop their disttag.
How many other repositories are there with the entire stack duplicated? (not being sarcastic.. I really don't know of any). I know that there were conflicts with Livna and what not a while ago, but those were for a handful of packages only.
As for JPackage dropping their release tag policy -- not to be the devil's advocate, but they were here before Fedora...
I have heard of numerous requests for technical arguments as to why the string is needed. But where the technical arguments as to why it should be removed? From what I have seen so far, reasons for that are pretty much "Because it looks better, because it a policy, etc."
It causes rpm ordering to be painful. The Version and Release should be wholly numeric, whenever they aren't, rpm's ordering gets rather non-intuitive. We've defined special, strictly controlled cases when it is ok to have non-numeric characters in the version or release (especially release), but only when there is a real need.
Okay, thanks for the clarification.
So, again, where is the real need for tacking jpp on the end of Release?
The need is compatibility with JPackage. Our Java stack is simply not big enough. Most of the Java packages in Fedora have gone in as direct and indirect dependencies of Eclipse and Maven. In other words, JPackage still has a large selection of directly usable Java apps.
*IF* we can convince JPackage to drop jpp, all would be fine. If we cannot -- are we willing to lose compatibility?
Btw, there is also middleground that I haven't seen being discussed: What if we drop the "jpp", but keep the X from Xjpp? So foo-1.0-1jpp becomes foo-1.0-1.1 in Fedora.
This would maintain compatibility, and would give us numeric releases.
The above compromise would cause us to lose the ability to gather a list of packages in the Java stack/common packages (with JPackage) though.
We had agreed on an "exit clause" of dropping this when the RPM/yum Capabilities (?) feature became available to replace the deprecated Groups, so we could mark packages with various attributes like "Java", "JPP" etc, and select them at will in all sorts of operations.
On Fri, 2008-03-28 at 09:50 -0400, Fernando Nasser wrote:
We had agreed on an "exit clause" of dropping this when the RPM/yum Capabilities (?) feature became available to replace the deprecated Groups, so we could mark packages with various attributes like "Java", "JPP" etc, and select them at will in all sorts of operations.
This could just as easily go in the "Group:" tag, and not complicate the n-v-r.
~spot
* Tom spot Callaway tcallawa@redhat.com [2008-03-28 12:55]:
On Fri, 2008-03-28 at 09:50 -0400, Fernando Nasser wrote:
We had agreed on an "exit clause" of dropping this when the RPM/yum Capabilities (?) feature became available to replace the deprecated Groups, so we could mark packages with various attributes like "Java", "JPP" etc, and select them at will in all sorts of operations.
This could just as easily go in the "Group:" tag, and not complicate the n-v-r.
No easy to sort with that though. With the release having jpp in there, one can just do rpm -qa | grep jpp
As for the reason why sort is needed... well, Java is sort of a special case in that it is the only set that has all packages available from a different vendor. So if someone wants to replace the Fedora Java stack with the JPackage Java stack or vice versa, they need to be able to easily find out the set..
Deepak
On Fri, 2008-03-28 at 14:23 -0400, Deepak Bhole wrote:
- Tom spot Callaway tcallawa@redhat.com [2008-03-28 12:55]:
On Fri, 2008-03-28 at 09:50 -0400, Fernando Nasser wrote:
We had agreed on an "exit clause" of dropping this when the RPM/yum Capabilities (?) feature became available to replace the deprecated Groups, so we could mark packages with various attributes like "Java", "JPP" etc, and select them at will in all sorts of operations.
This could just as easily go in the "Group:" tag, and not complicate the n-v-r.
No easy to sort with that though. With the release having jpp in there, one can just do rpm -qa | grep jpp
As for the reason why sort is needed... well, Java is sort of a special case in that it is the only set that has all packages available from a different vendor. So if someone wants to replace the Fedora Java stack with the JPackage Java stack or vice versa, they need to be able to easily find out the set..
This is a pretty silly line of reasoning. If people are replacing the entire stack, then _something_ is being done wrong.
Either we're a) providing an adequate and effective Java environment (... which is what I think we're doing) in which case, we don't _want_ our users going off and replacing things wholesale like you're saying. b) Or we're not. In which case, we should stop sucking and fix it.
If Java gets a free ride of specialness here, then why not do the same when someone start GPackage.org (with packages of all your GNOME desktop bits!) or KPackage.org. But we don't do that. In fact, we've explicitly worked hard such that the KDE bits in Fedora are good rather than having people go off and use kde-redhat (hats off to Rex for his work here)
Jeremy
* Jeremy Katz katzj@redhat.com [2008-03-28 14:29]:
On Fri, 2008-03-28 at 14:23 -0400, Deepak Bhole wrote:
- Tom spot Callaway tcallawa@redhat.com [2008-03-28 12:55]:
On Fri, 2008-03-28 at 09:50 -0400, Fernando Nasser wrote:
We had agreed on an "exit clause" of dropping this when the RPM/yum Capabilities (?) feature became available to replace the deprecated Groups, so we could mark packages with various attributes like "Java", "JPP" etc, and select them at will in all sorts of operations.
This could just as easily go in the "Group:" tag, and not complicate the n-v-r.
No easy to sort with that though. With the release having jpp in there, one can just do rpm -qa | grep jpp
As for the reason why sort is needed... well, Java is sort of a special case in that it is the only set that has all packages available from a different vendor. So if someone wants to replace the Fedora Java stack with the JPackage Java stack or vice versa, they need to be able to easily find out the set..
This is a pretty silly line of reasoning. If people are replacing the entire stack, then _something_ is being done wrong.
Either we're a) providing an adequate and effective Java environment (... which is what I think we're doing) in which case, we don't _want_ our users going off and replacing things wholesale like you're saying. b) Or we're not. In which case, we should stop sucking and fix it.
It is not a matter of sucking as much as a matter of completion. In my previous mail I stated this: A majority of our Java stack is just indirect dependencies of Eclipse and Maven. JPackage on the other hand has a lot more packages, many usable directly by the user.
In an ideal world, users would be able to mix and match packages from Fedora and JPackage. However, that is not always acceptable to users. For example, Fedora natively compiles most of the Java packages, has patches to make things build with gcj (com.sun.* packages for example), etc. JPackage on the other hard supports only proprietary vm's, so some packages have different packages and may behave slightly different.
If Java gets a free ride of specialness here, then why not do the same when someone start GPackage.org (with packages of all your GNOME desktop bits!) or KPackage.org. But we don't do that. In fact, we've explicitly worked hard such that the KDE bits in Fedora are good rather than having people go off and use kde-redhat (hats off to Rex for his work here)
Because neither GPackage nor KPackage exist. JPackage existed before Fedora did, and it's long existence is the reason it has such a large set of Java packages. Additionally, Java is far more portable than C/C++. A GPackage/KPackage could be more pain than they are worth, given that different distros have different libraries. With Java, that is not an issue ... that is what has sustained JPackage for so long.
Deepak
Deepak Bhole wrote:
- Tom spot Callaway tcallawa@redhat.com [2008-03-28 12:55]:
On Fri, 2008-03-28 at 09:50 -0400, Fernando Nasser wrote:
We had agreed on an "exit clause" of dropping this when the RPM/yum Capabilities (?) feature became available to replace the deprecated Groups, so we could mark packages with various attributes like "Java", "JPP" etc, and select them at will in all sorts of operations.
This could just as easily go in the "Group:" tag, and not complicate the n-v-r.
No easy to sort with that though. With the release having jpp in there, one can just do rpm -qa | grep jpp
As for the reason why sort is needed... well, Java is sort of a special case in that it is the only set that has all packages available from a different vendor. So if someone wants to replace the Fedora Java stack with the JPackage Java stack or vice versa, they need to be able to easily find out the set..
Deepak
The same happens when we are developing a new stack and on several other scenarios that were described and examined long ago. The conclusion was that the new RPM+Yum things was the solution for everything, and that by that time we would be able to remove that clause.
Tom "spot" Callaway wrote:
On Fri, 2008-03-28 at 09:50 -0400, Fernando Nasser wrote:
We had agreed on an "exit clause" of dropping this when the RPM/yum Capabilities (?) feature became available to replace the deprecated Groups, so we could mark packages with various attributes like "Java", "JPP" etc, and select them at will in all sorts of operations.
This could just as easily go in the "Group:" tag, and not complicate the n-v-r.
Unfortunately not. We've tried, remember? There were some bugs/limitations in rpm and yum that prevented us to use it (don't ask me to remember the details after so long, but it is in the archives). Over those 3 months we tried _everything_ in existance util we all concluded that we needed the new tag.
On Thu, 2008-03-27 at 15:13 -0400, Deepak Bhole wrote:
An important reason we need the jpp in there currently is to maintain compatibility with JPackage.
With the way the naming is right now, users can enable a JPackage repository beside a Fedora repo, and are guaranteed to get the latest either from Fedora or JPackage, whichever is newer.
Full stop. You can easily get this without the use of "jpp" text. I won't bother you with the details, but for this particular use of jpp you can absolutely do it without "jpp" in versions.
Without the jpp in the release tag, this compatibility is broken. And it goes beyond the packages themselves -- it also affects dependent packages,
Deepak Bhole wrote:
An important reason we need the jpp in there currently is to maintain compatibility with JPackage.
With the way the naming is right now, users can enable a JPackage repository beside a Fedora repo, and are guaranteed to get the latest either from Fedora or JPackage,...
...
e.g package foo is currently at 1.0-1jpp in jpackage and 1.0-1jpp.1 in
Stripping 'jpp' works fine (at least according to my quick-n-dirty use of rpmdev-vercmp:
1.0-1jpp < 1.0-2 < 1.0-2jpp
-- Rex
* Rex Dieter rdieter@math.unl.edu [2008-03-27 15:37]:
Deepak Bhole wrote:
An important reason we need the jpp in there currently is to maintain compatibility with JPackage. With the way the naming is right now, users can enable a JPackage repository beside a Fedora repo, and are guaranteed to get the latest either from Fedora or JPackage,...
...
e.g package foo is currently at 1.0-1jpp in jpackage and 1.0-1jpp.1 in
Stripping 'jpp' works fine (at least according to my quick-n-dirty use of rpmdev-vercmp:
1.0-1jpp < 1.0-2 < 1.0-2jpp
Until Fedora does a 1.0-3 to fix something, with the -3 still being split from the 1jpp, never having acquired the fixes from 1jpp->2jpp
Cheers, Deepak
-- Rex
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
On 27/03/2008, Deepak Bhole dbhole@redhat.com wrote:
With the way the naming is right now, users can enable a JPackage repository beside a Fedora repo, and are guaranteed to get the latest either from Fedora or JPackage, whichever is newer. Without the jpp in the release tag, this compatibility is broken. And it goes beyond the packages themselves -- it also affects dependent packages,
Is that actually true these days? I gave up on trying to use JPackage and Fedora together a while ago because there were incompatibilities that neither side seemed to be falling over themselves to fix.
Not that this is an argument for not allowing this again the future, of course, and possibly it does work again even now.
MEF
* Mary Ellen Foster foster@in.tum.de [2008-03-27 16:10]:
On 27/03/2008, Deepak Bhole dbhole@redhat.com wrote:
With the way the naming is right now, users can enable a JPackage repository beside a Fedora repo, and are guaranteed to get the latest either from Fedora or JPackage, whichever is newer. Without the jpp in the release tag, this compatibility is broken. And it goes beyond the packages themselves -- it also affects dependent packages,
Is that actually true these days? I gave up on trying to use JPackage and Fedora together a while ago because there were incompatibilities that neither side seemed to be falling over themselves to fix.
Not that this is an argument for not allowing this again the future, of course, and possibly it does work again even now.
There have been a few bumps along the way, yes :) However, it is our (Java Team's) intention to always allow smooth interoperability. We plan to have meeting with JPackage folks in the near term to iron out the current outstanding issues.
Deepak
MEF
-- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universität München and ICCS, School of Informatics, University of Edinburgh
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
On Tue, 2008-03-25 at 23:03 +0100, Nicolas Mailhot wrote:
Le mardi 25 mars 2008 à 17:06 -0400, Tom "spot" Callaway a écrit :
I'm not sure what this section is intended to provide. It seems to imply that the JPackage Guidelines are the real guidelines
[...]
It's canonical in the sense it's an external document we respect, just like the FHS, the freedesktop.org specs, etc are external conventions we respect. Must each of those documents be parroted in our guidelines to indicate we follow them?
+1
- "%{_jnidir} usually expands into /usr/lib/java." This should probably
be %{_libdir}/java.
The original jpp tools scripts are not multilib-safe (I didn't have a x86_64 system available when I wrote them). When the problem was identified by people with the right hardware, a quickfix (proposed by RH IIRC) consisted in changing all the %{_libdir}s in the original guidelines with /usr/lib.
Since then no one took the time to make the scripts multilib-safe.
Tom Fitzsimmons has said more than once this is on his list of things to do but he has yet to have time to accomplish it.
- It might also be worthwhile to do an "ant" spec template and a
"maven" spec template.
[...]
I fear the ant case is likely to be quite un-representative. It would be like making a "make" case without the GNU project having imposed strong conventions on standard makefile targets.
Agreed. A maven template is perHAPs more useful, but I'll let maven people take that one.
Andrew
Le Mer 26 mars 2008 14:28, Andrew Overholt a écrit :
On Tue, 2008-03-25 at 23:03 +0100, Nicolas Mailhot wrote:
Le mardi 25 mars 2008 à 17:06 -0400, Tom "spot" Callaway a écrit :
- "%{_jnidir} usually expands into /usr/lib/java." This should
probably
be %{_libdir}/java.
The original jpp tools scripts are not multilib-safe (I didn't have a x86_64 system available when I wrote them). When the problem was identified by people with the right hardware, a quickfix (proposed by RH IIRC) consisted in changing all the %{_libdir}s in the original guidelines with /usr/lib.
Since then no one took the time to make the scripts multilib-safe.
Tom Fitzsimmons has said more than once this is on his list of things to do but he has yet to have time to accomplish it.
BTW this was by no means an indictment, Tom Fitzsimmon is not the only one who could fix the scripts, it was just an explanation why putting %{_libdir} in guidelines now would explode horribly.
Regards,
Nicolas Mailhot wrote:
Le Mer 26 mars 2008 14:28, Andrew Overholt a écrit :
On Tue, 2008-03-25 at 23:03 +0100, Nicolas Mailhot wrote:
Le mardi 25 mars 2008 à 17:06 -0400, Tom "spot" Callaway a écrit :
- "%{_jnidir} usually expands into /usr/lib/java." This should
probably
be %{_libdir}/java.
The original jpp tools scripts are not multilib-safe (I didn't have a x86_64 system available when I wrote them). When the problem was identified by people with the right hardware, a quickfix (proposed by RH IIRC) consisted in changing all the %{_libdir}s in the original guidelines with /usr/lib.
Since then no one took the time to make the scripts multilib-safe.
Tom Fitzsimmons has said more than once this is on his list of things to do but he has yet to have time to accomplish it.
BTW this was by no means an indictment, Tom Fitzsimmon is not the only one who could fix the scripts, it was just an explanation why putting %{_libdir} in guidelines now would explode horribly.
The blocker currently is the rpm $1 bug which breaks alternatives when both 32- and 64-bit JDK packages are installed in parallel. I'm working on a fix for rpm, but it's not easy. Once that's fixed we can fix everything else properly. I already have jpackage-utils/JDK package patches for this that we've tested lightly internally. But they won't work properly until the the rpm bug is fixed.
Tom
Hi,
Thanks for the comments. I've tried to address them all. See my comments inline.
On Tue, 2008-03-25 at 17:06 -0400, Tom "spot" Callaway wrote:
- The JPackageNaming exception needs to die. It was a painful
compromise originally, and now, it just needs to be removed. I will vote -1 on any draft that contains it, unless someone comes up with a much more convincing rationale for its continued existence.
I'm going to leave this one to others (Fernando, etc.).
- "The JPackage Project has defined standard file system locations and
conventions for use in Java packages. Many distributions have inherited these conventions and in the vast majority of cases, Fedora follows them verbatim. We include relevant sections of the JPackage guidelines here but caution that the canonical document will always reside upstream: JPackage Guidelines "
I'm not sure what this section is intended to provide. It seems to imply that the JPackage Guidelines are the real guidelines, in which case, what point do the Fedora Guidelines serve? I have no problem giving the JPackage team credit for the origination of many of the Fedora Guidelines, but to refer to that as "the canonical document" is wrong. This is supposed to be the canonical document for Fedora Java Guidelines.
Are you satisfied with Nicolas' answer on this one?
- "If the number of provided JAR files exceeds two, place them into a
sub-directory." What makes two the magic number here? Why not simply more than 1?
Again, is Nicolas' answer okay here?
- "Java packages in Fedora should enumerate their dependencies with
Requires." I think this might need to be a "must", not just a "should".
Fixed.
- I would like to see a section reminding people that all Java packages
MUST be built from source code, and that pre-built binary files (JARs or otherwise) are not acceptable. The "Pre-built JAR files / Other bundled software" is probably intended to do this, but it uses a lot of "shoulds", and never explicitly states that this must not happen.
Fixed.
- Please add an example of how to resolve class-path-in-manifest
issues.
Done (although I have a small question about it. I put it on the page if someone can take a look.).
- Go through the entire document and make sure that you're using "must"
and "should" appropriately. "Should" means that you are not required to do it, its just a good idea. "Must" means that you are required to do it, and that it will fail a package on review. For example, the "Javadoc scriptlets" seems like it is a "must" not a "should".
I think I got all of this.
- "%{_jnidir} usually expands into /usr/lib/java." This should probably
be %{_libdir}/java.
I'd like Tom to comment here but I'm not sure multilib-ifying jpackage-utils is possible right now.
- I think you've got an accidental line wrap in the example for
"Packaging JAR files that use JNI"
Is this fixed now?
- It might also be worthwhile to do an "ant" spec template and a
"maven" spec template. I'm not sure how different these two packaging types would be, but the guidelines seem to imply significant differences.
Do the other messages in this thread satisfy you that this isn't worth it?
Thanks,
Andrew
On Wed, 2008-03-26 at 10:14 -0400, Andrew Overholt wrote:
Are you satisfied with Nicolas' answer on this one?
I'd still prefer a rewording there, to clearly state that if/when the two documents are in conflict, the Fedora Java Guidelines win.
- "If the number of provided JAR files exceeds two, place them into a
sub-directory." What makes two the magic number here? Why not simply more than 1?
Again, is Nicolas' answer okay here?
Sure.
- "%{_jnidir} usually expands into /usr/lib/java." This should probably
be %{_libdir}/java.
I'd like Tom to comment here but I'm not sure multilib-ifying jpackage-utils is possible right now.
Is nothing in the Java space multilib? If not, maybe we can let this slide as is, but I suspect lots of Java stuff is multilib, and we need to get this fixed.
- I think you've got an accidental line wrap in the example for
"Packaging JAR files that use JNI"
Is this fixed now?
Looks good.
- It might also be worthwhile to do an "ant" spec template and a
"maven" spec template. I'm not sure how different these two packaging types would be, but the guidelines seem to imply significant differences.
Do the other messages in this thread satisfy you that this isn't worth it?
To be honest, no. If we're going to have maven based packages, I would feel much better about having an example template.
~spot
* Tom spot Callaway tcallawa@redhat.com [2008-03-26 10:21]:
On Wed, 2008-03-26 at 10:14 -0400, Andrew Overholt wrote:
Are you satisfied with Nicolas' answer on this one?
I'd still prefer a rewording there, to clearly state that if/when the two documents are in conflict, the Fedora Java Guidelines win.
Done. Let me know if it's not good enough.
- "%{_jnidir} usually expands into /usr/lib/java." This should probably
be %{_libdir}/java.
I'd like Tom to comment here but I'm not sure multilib-ifying jpackage-utils is possible right now.
Is nothing in the Java space multilib? If not, maybe we can let this slide as is, but I suspect lots of Java stuff is multilib, and we need to get this fixed.
Java stuff is noarch, normally. Existing packages that are built with gcj have lots of workarounds to deal with multilib issues (brp-repack-jars; the unpacking and repacking of jars to set the creation dates to 1980-01-01 at the end of eclipse.spec, etc.). It will be nice to fix these issues and having OpenJDK JIT support on more arches will help.
fitzsim, any more thoughts here?
- It might also be worthwhile to do an "ant" spec template and a
"maven" spec template. I'm not sure how different these two packaging types would be, but the guidelines seem to imply significant differences.
Do the other messages in this thread satisfy you that this isn't worth it?
To be honest, no. If we're going to have maven based packages, I would feel much better about having an example template.
Deepak, can you do a maven one? I really think doing an ant one is a waste of time (and the main template uses ant anyway).
Andrew
* Andrew Overholt overholt@redhat.com [2008-03-26 11:22]:
- Tom spot Callaway tcallawa@redhat.com [2008-03-26 10:21]:
On Wed, 2008-03-26 at 10:14 -0400, Andrew Overholt wrote:
Are you satisfied with Nicolas' answer on this one?
I'd still prefer a rewording there, to clearly state that if/when the two documents are in conflict, the Fedora Java Guidelines win.
Done. Let me know if it's not good enough.
- "%{_jnidir} usually expands into /usr/lib/java." This should probably
be %{_libdir}/java.
I'd like Tom to comment here but I'm not sure multilib-ifying jpackage-utils is possible right now.
Is nothing in the Java space multilib? If not, maybe we can let this slide as is, but I suspect lots of Java stuff is multilib, and we need to get this fixed.
Java stuff is noarch, normally. Existing packages that are built with gcj have lots of workarounds to deal with multilib issues (brp-repack-jars; the unpacking and repacking of jars to set the creation dates to 1980-01-01 at the end of eclipse.spec, etc.). It will be nice to fix these issues and having OpenJDK JIT support on more arches will help.
fitzsim, any more thoughts here?
- It might also be worthwhile to do an "ant" spec template and a
"maven" spec template. I'm not sure how different these two packaging types would be, but the guidelines seem to imply significant differences.
Do the other messages in this thread satisfy you that this isn't worth it?
To be honest, no. If we're going to have maven based packages, I would feel much better about having an example template.
Deepak, can you do a maven one? I really think doing an ant one is a waste of time (and the main template uses ant anyway).
Sure. I will write one up later today and put it on the wiki.
Deepak
Andrew Overholt wrote:
- Tom spot Callaway tcallawa@redhat.com [2008-03-26 10:21]:
On Wed, 2008-03-26 at 10:14 -0400, Andrew Overholt wrote:
Are you satisfied with Nicolas' answer on this one?
I'd still prefer a rewording there, to clearly state that if/when the two documents are in conflict, the Fedora Java Guidelines win.
Done. Let me know if it's not good enough.
- "%{_jnidir} usually expands into /usr/lib/java." This should probably
be %{_libdir}/java.
I'd like Tom to comment here but I'm not sure multilib-ifying jpackage-utils is possible right now.
Is nothing in the Java space multilib? If not, maybe we can let this slide as is, but I suspect lots of Java stuff is multilib, and we need to get this fixed.
Java stuff is noarch, normally. Existing packages that are built with gcj have lots of workarounds to deal with multilib issues (brp-repack-jars; the unpacking and repacking of jars to set the creation dates to 1980-01-01 at the end of eclipse.spec, etc.). It will be nice to fix these issues and having OpenJDK JIT support on more arches will help.
fitzsim, any more thoughts here?
Java will not properly support multilib until this longstanding rpm bug is fixed:
https://bugzilla.redhat.com/show_bug.cgi?id=340391
It causes alternatives symlink breakage when 32- and 64-bit JDKs are installed in parallel.
Recently, I've been working on a patch to rpm to fix this, but it's taking me longer than I had hoped.
After that's fixed there still remains: making jpackage-utils itself multilib, making the JDK packages multilib-compatible, (we already have patches for these first two), and testing the upgrade paths from noarch jpackage-utils to multilib jpackage-utils, and the upgrade paths from no-multilib-support JDK packages to multilib-supporting JDK packages. These upgrade path tests will need to be done for Fedora and RHEL packages.
I was trying to have this done by Fedora 9, but we'll have to aim for Fedora 10 now. It could even be considered a full-fledged Fedora 10 "Feature".
Tom
Le Mer 26 mars 2008 15:21, Tom "spot" Callaway a écrit :
- "%{_jnidir} usually expands into /usr/lib/java." This should
probably
be %{_libdir}/java.
I'd like Tom to comment here but I'm not sure multilib-ifying jpackage-utils is possible right now.
Is nothing in the Java space multilib? If not, maybe we can let this slide as is, but I suspect lots of Java stuff is multilib, and we need to get this fixed.
JVMs and JNI bits are multilib. Though before openjdk the x86_64 port was too broken to be widely used.
On Tuesday 25 March 2008, Andrew Overholt wrote:
http://fedoraproject.org/wiki/PackagingDrafts/Java
All of the questions and comments and TODOs that were on the page have been taken care of. I'm sure there are going to be questions and complaints, but we now feel it's in a state worthy of first draft presentation.
I'd like to draw some attention to my question about why to install the versioned jars. Nicolas is trying to help me understand, but I'm either correct in that they should just be dropped or too dumb so far to get it (in which case I think it needs a real explanation in the guidelines):
https://www.redhat.com/archives/fedora-devel-list/2008-March/msg02346.html
Ville Skyttä wrote:
On Tuesday 25 March 2008, Andrew Overholt wrote:
http://fedoraproject.org/wiki/PackagingDrafts/Java
All of the questions and comments and TODOs that were on the page have been taken care of. I'm sure there are going to be questions and complaints, but we now feel it's in a state worthy of first draft presentation.
I'd like to draw some attention to my question about why to install the versioned jars. Nicolas is trying to help me understand, but I'm either correct in that they should just be dropped or too dumb so far to get it (in which case I think it needs a real explanation in the guidelines):
https://www.redhat.com/archives/fedora-devel-list/2008-March/msg02346.html
Yes, I've struggled to understand the same decision in the JDK packages. I wonder why the extra level of versioning is required:
$ ls -l /usr/lib/jvm/java-1.7.0-icedtea lrwxrwxrwx 1 root root 26 2007-12-11 14:36 /usr/lib/jvm/java-1.7.0-icedtea -> java-1.7.0-icedtea-1.7.0.0
Nicolas, do you know the rationale? To enable parallel-installation of multiple versions of the same JDK, perhaps?
Tom
Le Jeu 27 mars 2008 15:57, Thomas Fitzsimmons a écrit :
Ville Skyttä wrote:
Yes, I've struggled to understand the same decision in the JDK packages. I wonder why the extra level of versioning is required:
$ ls -l /usr/lib/jvm/java-1.7.0-icedtea lrwxrwxrwx 1 root root 26 2007-12-11 14:36 /usr/lib/jvm/java-1.7.0-icedtea -> java-1.7.0-icedtea-1.7.0.0
Nicolas, do you know the rationale? To enable parallel-installation of multiple versions of the same JDK, perhaps?
When you are in closed JVM hell you need to manage black-boxes and for this reason switching between different JVMs (or different builds of the same JVM) is very common (talking from an ISV perspective which was my job when I wrote the guidelines). You can't trust the vendor to fix its bugs timely. You can't trust it not to create regressions in a new build (that will take forever to ve fixed). All you can do it get a range of jvms and switch between them till you identify the most solid.
When openjdk gets solid enough people trust the OS jvm, and when java projects get the clue they need to work with any JVM not just the particular build they copied in their private build system, I expect those possibilities to gradually fall into disuse. But right now easy JVM switching is a must for users.
On Thu, Mar 27, 2008 at 11:59 AM, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
Le Jeu 27 mars 2008 15:57, Thomas Fitzsimmons a écrit :
Ville Skyttä wrote:
Yes, I've struggled to understand the same decision in the JDK packages. I wonder why the extra level of versioning is required:
$ ls -l /usr/lib/jvm/java-1.7.0-icedtea lrwxrwxrwx 1 root root 26 2007-12-11 14:36 /usr/lib/jvm/java-1.7.0-icedtea -> java-1.7.0-icedtea-1.7.0.0
Nicolas, do you know the rationale? To enable parallel-installation of multiple versions of the same JDK, perhaps?
When you are in closed JVM hell you need to manage black-boxes and for this reason switching between different JVMs (or different builds of the same JVM) is very common (talking from an ISV perspective which was my job when I wrote the guidelines). You can't trust the vendor to fix its bugs timely. You can't trust it not to create regressions in a new build (that will take forever to ve fixed). All you can do it get a range of jvms and switch between them till you identify the most solid.
When openjdk gets solid enough people trust the OS jvm, and when java projects get the clue they need to work with any JVM not just the particular build they copied in their private build system, I expect those possibilities to gradually fall into disuse. But right now easy JVM switching is a must for users.
Another reason for parallel JVM installation is when you're working on different releases of a product that requires different JVM levels. For instance, I might have one that is certified to use 1.4.2 and another that requires 1.6.0. I might be able to run my 1.4.2 under 1.6.0 but that's not always feasible.
jesus rodriguez
packaging@lists.fedoraproject.org