Meeting minutes and full logs of the packaging committee meeting which occurred on 2008-04-01 are online:
http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes20080401
Executive summary:
The following drafts are now official guidelines, having been accepted by FESCO last week:
* ASCII Naming Guidelines: http://fedoraproject.org/wiki/PackagingDrafts/ASCIINaming * New Perl Guidelines: http://fedoraproject.org/wiki/PackagingDrafts/Perl * OpenOffice.org extensions guidelines: http://fedoraproject.org/wiki/PackagingDrafts/OpenOffice.orgExtensions
These should be written into the guidelines soon if this hasn't already been done by the time you read this.
Issues pending FESCO ratification:
Java guidelines * http://fedoraproject.org/wiki/PackagingDrafts/Java * This is the first vote for this draft, but it's the culmination of significant work and discussion * Accepted (5 - 1)
* SysV-style initscript guidelines * http://fedoraproject.org/wiki/PackagingDrafts/SysVInitScript * This is a new draft this week * Accepted (6 - 0)
* Eclipse plugin guidelines * http://fedoraproject.org/wiki/PackagingDrafts/EclipsePlugins * This was previously discussed and withdrawn at a previous meeting and is back up for a vote. * Accepted (6 - 0)
* Guidelines for the use of GCJ in Java packages * http://fedoraproject.org/wiki/PackagingDrafts/GCJGuidelines * A new submission this week; the Java guidelines refer to it. * Accepted (5 - 0)
Misc business:
* FPC will meet again April 8, and will then hopefully return to meeting every other week.
- J<
On Wed, Apr 2, 2008 at 12:42 PM, Jason L Tibbitts III tibbs@math.uh.edu wrote:
Java guidelines
- http://fedoraproject.org/wiki/PackagingDrafts/Java
- This is the first vote for this draft, but it's the culmination of significant work and discussion
- Accepted (5 - 1)
Where should questions about the Java guidelines be directed? This list? The wiki page?
I'm curious about two points. First, rpmlint can either complain that jars are indexed, or complain that they are not indexed. In the default Fedora configuration, it complains if they are indexed. Why? Is there some supported JVM on some supported Fedora release that cannot handle indexed JARs? I don't see anything about this in the JPackage guidelines, nor in the Fedora guidelines.
Second, I have a question about the use of Class-Path in JAR manifests. The JPackage guidelines say nothing about it. The Fedora guidelines only give a sed command to remove Class-Path entries, but do not discuss why they should be removed. Rpmlint says, "These entries do not work with older Java versions and even if they do work, they are inflexible and usually cause nasty surprises." What older Java versions? Any that we care about? In what way are they inflexible? What nasty surprises have been encountered?
Thanks,
"JJ" == Jerry James loganjerry@gmail.com writes:
JJ> Where should questions about the Java guidelines be directed? JJ> This list? The wiki page?
This list should be fine, or there is a comments section at the bottom of the wiki page. Unfortunately I cannot really provide answers to your questions, because I am not well-versed in the intricacies of Java.
- J<
Hi,
On Wed, 2008-04-02 at 13:24 -0600, Jerry James wrote:
I'm curious about two points. First, rpmlint can either complain that jars are indexed, or complain that they are not indexed. In the default Fedora configuration, it complains if they are indexed. Why? Is there some supported JVM on some supported Fedora release that cannot handle indexed JARs? I don't see anything about this in the JPackage guidelines, nor in the Fedora guidelines.
No one brought up the indexing issue. I've never seen that rpmlint warning myself. Perhaps you should ask Ville.
Second, I have a question about the use of Class-Path in JAR manifests. The JPackage guidelines say nothing about it. The Fedora guidelines only give a sed command to remove Class-Path entries, but do not discuss why they should be removed.
This was discussed during the process of editing the page:
"the problem with classpathes-in-manifest is you hardcode the location of other jar files inside a file. So any common file operation like copying, renaming, moving the referenced file or the jar itself will break the classpath and trigger difficult-to-debug failures. When the classpath is in a single place and not hidden in part inside jar files maintenance is much easier and file operations do not require doing surgery inside jar files - NicolasMailhot"
Feel free to request that justification be listed on the page (I really don't know the process for making changes to guidelines after they're voted upon by FPC), but I don't think it should be added right now since these guidelines are in the process of FPC->FESCo ratification and shouldn't be touch (AIUI).
Andrew
On Wednesday 02 April 2008, Andrew Overholt wrote:
Hi,
On Wed, 2008-04-02 at 13:24 -0600, Jerry James wrote:
I'm curious about two points. First, rpmlint can either complain that jars are indexed, or complain that they are not indexed. In the default Fedora configuration, it complains if they are indexed. Why?
Which version of rpmlint are you using? Have you touched related rpmlint configuration settings? rpmlint's current default configuration in Fedora should prevent it from emitting any messages whatsoever about jars being indexed or not.
Upstream rpmlint's default configuration is to whine if jars are not indexed (config parameter UseIndexedJars defaults to 1, this is what Fedora uses too), but we filter warnings about non-indexed jars out from the output, see "grep jar /usr/share/rpmlint/config".
If you're seeing jar indexing related warnings using the default rpmlint config, I'm pretty sure that would be an rpmlint or rpmlint packaging bug.
Is there some supported JVM on some supported Fedora release that cannot handle indexed JARs? I don't see anything about this in the JPackage guidelines, nor in the Fedora guidelines.
No one brought up the indexing issue. I've never seen that rpmlint warning myself. Perhaps you should ask Ville.
Indexing supposedly speeds up classloading in some cases, and is probably most useful with applets loaded over the network. I've never seen any numbers related to this though, neither for the over the network case nor for normal local java apps, nor do I know if non-network classloaders that process jar indexes exist in the first place.
On the other hand, indexed jars did break with some old Java versions, but I don't think that's of any relevance any more. But there's still one gotcha: indexing a jar will cause its manifest Class-Path to be ignored even with recent Java implementations (at least when invoked with "java -jar"). This is probably not much to worry about in Fedora as we don't want Class-Paths in manifests anyway, but can be useful to know.
If there is consensus that having rpmlint always whine about non-indexed jars or always about indexed jars would be a good thing, I can make either change in the package. Personally, I obviously couldn't choose :)
Second, I have a question about the use of Class-Path in JAR manifests. The JPackage guidelines say nothing about it. The Fedora guidelines only give a sed command to remove Class-Path entries, but do not discuss why they should be removed.
This was discussed during the process of editing the page:
[...]
Feel free to request that justification be listed on the page (I really don't know the process for making changes to guidelines after they're voted upon by FPC), but I don't think it should be added right now since these guidelines are in the process of FPC->FESCo ratification and shouldn't be touch (AIUI).
I'm not sure either, but adding the rationale sometime would be a good thing.
Ditto would be noting somewhere that the process of removing Class-Paths from manifests will break "java -jar foo.jar" invocations if foo.jar requires additional user stuff in the classpath. This is because $CLASSPATH, -cp and -classpath are ignored with "java -jar"; only Class-Path in manifest works with it. The workaround is to not use -jar but use the main class name instead, and set classpath the usual way as required. Packagers should therefore not use "java -jar" in any scripts or docs, and this could be a good thing to note in end user docs as well.
* Ville Skyttä ville.skytta@iki.fi [2008-04-02 17:10]:
Ditto would be noting somewhere that the process of removing Class-Paths from manifests will break "java -jar foo.jar" invocations if foo.jar requires additional user stuff in the classpath. This is because $CLASSPATH, -cp and -classpath are ignored with "java -jar"; only Class-Path in manifest works with it. The workaround is to not use -jar but use the main class name instead, and set classpath the usual way as required.
Yup.
Packagers should therefore not use "java -jar" in any scripts or docs, and this could be a good thing to note in end user docs as well.
Yeah.
Andrew
-
Andrew Overholt -
Jason L Tibbitts III -
Jerry James -
Ville Skyttä