Archive:PackagingDrafts/JavaPackageNaming

Naming Conventions for Packages Adapted from JPackage

This draft document is obsolete. The approved JPackage adoption guidelines are found here: [wiki:Self:Packaging/JPackagePolicy Subrelease Packaging Guidelines for JPackage RPMS]

Problem Space

Many Java programs are first packaged by the jpackage project . In essence, the Fedora packages have two upstreams: The upstream project itself and the jpackage project's spec file and patches. Fedora imports a package from jpackage and makes changes to enable native AOT compilation via gcj and bugfixes that have not been merged into either of the upstreams.

Presently, Core's jpackage-based packages have reflected the package origin within the package Release: 1jpp_2fc In this scheme, the 1jpp is the upstream jpackage release, _ is a separator, and 2fc is the Fedora release. (Note, this scheme is not currently as defined as the Fedora Naming Guidelines. So there are some practices above the base standard that would need to change.) This scheme has two expressed goals:

1. Allow for upgrading between the Fedora and JPackage repositories so that upgrade paths similar to the following works:

java-foo-1.0-1jpp_2fc [Fedora Release] 
java-foo-1.0-2jpp     [Updated JPackage Release] 
java-foo-1.0-2jpp_3fc [Updated Fedora Release rebased against the new JPackage] 

2. Allow users and packagers to tell what JPackage release the java package was based against.

3. A third expressed goal that conflicts with 1. is to upgrade Fedora packages only with Fedora packages and jpackage packages with jpackage packages.

Which naming guideline is chosen depends in large part on whether these are judged to be worthwhile and attainable goals.

Discussion of the goals

Goal #1

If JPackage were truly an upstream then we wouldn't want users to upgrade Fedora Packages with JPackage. We have bugfixes, local changes, and other patches that we add to packages to make them work better on Fedora. Having users upgrade between upstream and our packages is not a goal with any other upstream. gbenson states this here although he phrases it in the specifics of Fedora/JPackage instead of the general Fedora/Upstream.

There could be times when the jpackage naming is not compliant in the name, version, or release fields. When this happens, we would not be able to attain this goal. For instance: cryptix-asn1-20011119-4jpp_2fc.1.1.src.rpm. The version field must be changed before importing otherwise the final release of cryptix-asn1-1.0 will not upgrade the package.

Goal #2

Users shouldn't need this information. The Fedora Package may have more fixes than the JPackage one. It may be synced with more upstream bugfixes. It may contain snapshots of JPackage work that haven't hit the repositories yet because JPackage is working on a new major release. If the package works without bugs then the end user is happy.

Developers can use this information. But they aren't going to be staring at the package name most of the time. When they checkout from cvs, they'll have a spec file, not an RPM so the filename is no help. They have to look inside the spec file at which point it's just as easy to put the information in the %description, a Provides, or a comment. Using a Provides makes it queryable from the rpm command line as well.

Goal #3

This is not truly implementable via the package release tag.

Separating the native libraries into a subpackage might have some bearing on this.

Proposals

Removal of jpp From Release

This method seeks to meet Goal #1 and Goal #2. A Fedora package that is based on a jpp package is really a release greater than a jpp package. By realizing this and bumping the jpp number but leaving out jpp in the Fedora package we can provide an RPM newer package release than the existing jpp, while also providing an RPM older package than the next jpp release. EG:

JPackage
foo-1.0-6jpp

becomes

Fedora
foo-1.0-7.fc6

Our Fedora package is rpm newer. Then JPackage releases:

Jpackage
foo-1.0-7jpp

this is rpm newer than our 7.fc6. Once Fedora recompiles we get:

Fedora
foo-1.0-8.fc6

and once again we are newer than jpackage. This also allows Fedora to respin a package release and not disrupt the version:

Fedora
foo-1.0-8.fc6.1

This package will still be older than the next 8jpp release.

Discussion

By looking at the package name, it is not immediately appearent that this package is based on a JPackage release. A comment could exist in the spec file, or in the Summary or Description.

This method also fails to address the JPackage snapshot/prerelease versioning, but they are inconsistent. We need JPackage to address this and hopefully choose a method that meshes well with our guidelines.

Major bonuses to this options are:

• No changes to Fedora Package Guidelines
• No changes to jpp naming guidelines (with exception to pre-release / snapshot)
• Immediately able to fix existing JPackage based packages in Core to adhere to Guidelines without breaking upgrade paths
• Generic enough to be usable with another JPackage like situation should it arise, no special casing required

---

Minor Cleanups

As stated earlier, the current jpackage-based naming is not as stringent as the Fedora Naming Guidelines. The stringency of the naming guidelines is designed to make sure the upgrade path between Fedora Core releases is not inadvertently broken. With the minor cleanups approach, these guidelines are incorporated into the package by simply prefixing a valid Fedora Release string with the JPackage release number and a period::

<JPPRELEASE>.<FEDORARELEASE>

This is similar to what is done now with "_" replaced with a ".". There are other cleanups hidden in FEDORARELEASE, however. For instance, bsh-1.3.0-5jpp_1fc.1.1.src.rpm is still invalid. It needs to be either bsh-1.3.0-5jpp.2.fc5.src.rpm or bsh-1.3.0-5jpp.2.fc5.1.src.rpm depending on the intended purpose of 1.1 in the original release. Also note that .fc5 is supplied by the disttag macro. So the spec file would read:

Release: 5jpp.2%{?dist}

This assumes that the JPPRELEASE is able to upgrade cleanly in all the areas that the Fedora Naming Guidelines currently support. If the JPackage version and release aren't strict enough then this will have to be modified. pre and post releases that use alpha tags and cvs snapshots are some of the tricky areas that the Fedora Guidelines address and the JPackage RELEASES would have to as well.

Discussion

This is close to what exists now. It grants goals 1 and 2 above if those are truly wanted.

This would force Fedora Packagers and reviewers to understand 2 separate naming guidelines, the JPackage ones and the Fedora ones. This is going to cause confusion for new packagers and reviewers.

There are also some jpackaged rpms that I have concerns about the way they implement NEVR. For instance, cvs snapshot tags are inconsistent. jpp places Xjpp at the end of the string so switching, for example from milestones to snapshots and back breaks upgrading or requires a special case in the guidelines:

JPackage:
axion-1.0-0.M3.1jpp
axion-1.0-0.20060707.1jpp
axion-1.0-0.M4.1jpp <= broken   or    axion-1.0-1.M4.1jpp <= special case to bump the prerelease 0 to a 1.

Our Naming:
axion-1.0-0.1.M3.fc5
axion-1.0-0.2.20060707.fc5
axion-1.0-0.3.M4.fc5

If JPackage was willing, they could change their naming guidelines to be closer to ours which would: 1. take care of the above NEVR problem 2. Make it so a Fedora packager/reviewer would only have to understand how to combine the JPackage and Fedora versions.

---

Treat the JPackage Version Like a PostRelease

Since the JPackage Version is an enhancement of the true upstream release, the Naming Guidelines could be modified to place version in the name similar to the current post release snapshots::

(0.)?<INT>.<JPPRELEASE>%{?dist}

This is reasonable for most packages: bsh-1.3.0-2.5jpp.fc5.src.rpm For packages which have snapshots in the release, we woud treat jpackage as upstream, so we'd just use their tag to express snapshot status::

cryptix-asn1-0.0-0.1.20011119cvs.4jpp.fc5.src.rpm

Discussion

This meets goal 2. but not goal 1. This is a small modification of the current guidelines. We would want to make clear that jpackage is special because Fedora implements the JPackage framework for Java Packages and so they are the upstream that we sync our spec files against. This naming would not apply to any repository that did not share this kind of relationship with us.

---

Leave JPackage Information Out of the Name

JPackage packages will then follow the standard Fedora Naming like everyone else. This is what will happen if no other proposals are approved by the packaging committee.

Java packages based on upstream jpackage spec files should use: Provides: jpackage(%name) = %jpackage_version-%jpackage_release

so that the jpackage version is available in the spec file and from the commandline.

Discussion

This does not meet goal 1. It implements an alternative to goal 2. It is consistent with the existing guidelines.