The following metadata was found in MoinMoin that could not be converted to a useful value in MediaWiki:
- : make sure there are no JAR files left
Comments moved from the bottom of the original draft
- Which version of java should stuff be built for? Probably 1.5 (for gcj) if possible? Should mention something about this. (VilleSkyttä)
- I think referencing the GCJ Guidelines, which say the package should build on GCJ, is sufficient, since building on GCJ implies building on 1.5. In general packages should build against/require whatever Java version upstream uses. (ThomasFitzsimmons)
- Referring to GCJ guidelines would work for me, but the 1.5 issue needs to be explicitly mentioned there, it's not clear to everyone. (VilleSkyttä)
- "Requires: java" should have a version in it (depending on which version of java it was built for). Possibly also depend on jre instead of java (maybe this is just cosmetic)? (VilleSkyttä)
- Agreed. I removed the conditional brackets around >= specific_version. I think we should just stick with "java" and not bother with "jre", since that's how it's been done in the past. (ThomasFitzsimmons)
- Thanks. Spec templates still have the unversioned form, though. (VilleSkyttä)
- Drop versioned jars and install only unversioned ones? https://www.redhat.com/archives/fedora-devel-list/2008-March/msg02346.html (VilleSkyttä)
- Fine by me. (ThomasFitzsimmons)
- For users attempting to introduce a new Java package, we should tell them to first check if the package exists on JPackage (JPackage.org). JPackage packages follow a large majority of the guidelines in this draft, and thus importing should be fairly easy. Additionally, having a package in sync with JPackage will prevent potential incompatibility issues with other JPackage packages. (DeepakBhole)
- Would we want that to be a should or a must? In other words, if a packager wants to deviate from the JPackage package but still falls within the Guidelines do we want to allow them that freedom?
- My one major issue with this Guideline is the use of "canonical document" in the header for "Java Packaging". We do have other Guidelines that point to external sources for additional sources but they are targeted pieces (For instance, make sure .desktop files provided by the package follow the freedesktop spec [LINK to spec] ). The Java Guidelines are broader and also have an overlay of information (saying that the JPackage Guidelines are the "canonical document" seems to mean "follow the JPackage Guidelines except where the Fedora Guidelines differ"). This makes it harder for a reviewer to understand what's going on in a package that they attempt to review because they need to keep flipping between two Guidelines and trying to remember where one differs from another. It would be better organization if the Java Guidelines took one of the following approaches: 1) Major concerns listed in the Fedora Guidelines. Specifics point to the relevant section of the JPackage Guidelines. For instance:
=== Jar File Naming === Jar files must be named after the package name using the [http://www.jpackage.org/cgi-bin/viewvc.cgi/src/jpackage-utils/doc/jpackage-1.5-policy.xhtml?revision=HEAD&root=jpackage#id2434750 JPackage Jar File Naming Guideline]
For something that differs we could note the derivation and that our Guidelines take precedence:
=== Jar File Naming === Our rules are derived from the [http://www.jpackage.org/cgi-bin/viewvc.cgi/src/jpackage-utils/doc/jpackage-1.5-policy.xhtml?revision=HEAD&root=jpackage#id2434750 JPackage Guidelines] but we don't use versioned names for jars. Please use the following rules instead: [...]
The alternative to this would be to have people read the entirety of the JPackage Guidelines and then point out the places that we differ. We would probably want to do that by importing the JPackage Guidelines to the wiki and annotating the few cases where we differ. Note that we would probably want to decide whether resyncing when JPackage changes a Guidelines be done automatically or if the new version had to be brought in through FPC -> FESCo approval. We would also need someone from the Java team to do that resyncing as we might otherwise be unaware of the changes.
Item to clarify
(Section) ...substitute text...