Packaging/JPackage Policy

From openSUSE

Subrelease Packaging Guidelines for JPackage RPMS

Author: Tom 'spot' Callaway
Reviewed for SUSE by: mvyskocil
Revision: 0.06
Initial Draft: Tuesday Jan 16, 2007
Last Revised: Friday Mar 13, 2009

Summary

Warning

Those rules should be applied only for packages in Java:jpackage-5.0 repository. Existing openSUSE repositories are not compatible with this Policy, and rpm packages from jpackage.org has a regular tuple commit_number.build_number as any other package in SUSE, which is not compatible with those policy.

Java:jpackage-5.0 includes a set of open source Java RPM packages that originate from the JPackage repository (www.jpackage.org).

javacc-4.0-3jpp.3.src.rpm

openSUSE does not permit "repotags" in its packages. It is necessary to remove the "jpp" component in the Fedora version of these packages. Some additional guidelines have been drafted for these packages.

Managing upgrading packages from Java:jpackage-5.0 to JPackage and back

According to Fernando Nasser, JPackage RPMS only use integers in the Release: field, in the format Xjpp. If this is the case, then the following format will ensure clean upgrades from Java:jpackage-5.0 to JPackage and so forth:

JPackage RPMS have a Release of Xjpp (e.g. 1jpp). Java:jpackage-5.0 RPMS (which are taken from JPackage) will have a Release that takes the JPackage Release (Xjpp), removes the repotag (jpp) and appends a subrelease integer (Y). This will make the Java:jpackage-5.0 Java packages have a Release of: X.C.B (e.g. 1.1.1).

The C means a commit number and is increased by every commit of package to project. The B means a number of builds of this package. Those numbers are handled automatically by BuildService.

The Java:jpackage-5.0 repository has a following line in prjconf:

 Release: %%{?jpp_release}.<C_CNT>.<B_CNT>

where rpm macro jpp_release must be defined in a spec file and must contains the same value as is in Release: tag in spec file (the %{?dist} macro should be excluded). In this way we could manage a compatibility between our Java:jpackage-5.0 and upstream one.

Normally, we'd give the packager the choice of using '%{?dist}' or bumping the release to ensure clean upgrades across openSUSE releases, but since we're trying to ensure hierarchy and upgrades from the JPackage repository, in this special case, use of the '%{?dist}' tag is mandatory. It would go at the end of the Release: field, (e.g. 1.1%{?dist})

As those rules are imported from Fedora, which uses a different build system without automatic handling of Release tag, a table written above is just for clarification. For Java:jpackage-5.0 packager must makes sure, that he updates a %{jpp_release} macro, other numbers are handled by BuildService.

Pre-release Packages

JPackage has a Release standard of: 0.X.tag.Yjpp for prerelease packages. Tag is where the alpha/beta/CVS/SVN/etc tag goes, X is an integer incremented upon tag changes, and Y is an integer which increments only for packaging fixes, plain rebuilds etc. This is based on Fedora's pre-release naming standards. The same Subrelease policy is in effect for JPackage derived pre-release Packages in SUSE, on top of the existing [wiki:Self:Packaging/NamingGuidelines#PreReleasePackages pre-release guidelines].

Track Package Hierarchy From JPackage to Java:jpackage-5.0

With the subrelease scheme as documented above, it is very obvious from which JPackage RPM the SUSE Java package originated from.

Policy Conditions Defined

• Java:jpackage-5.0 Java packages (which have a relationship to JPackage packages) must follow the subrelease versioning as defined in this document.
• No other packages fall under this policy (at this time).
• Packagers of Java:jpackage-5.0 Java packages need to explicitly agree to this policy during package review.
• It needs a discussion if those rules would (and could be) adopted by SUSE itself.