m (Packaging/OldJPackagePolicy moved to Packaging:OldJPackagePolicy: Moving Packaging Pages to Packaging Namespace) |
m (moved Packaging:OldJPackagePolicy to Archive:Packaging:OldJPackagePolicy: Moved to archive) |
(No difference)
|
Revision as of 19:16, 17 February 2010
Subrelease Packaging Guidelines for JPackage RPMS
Author: Tom 'spot' Callaway
Revision: 0.05
Initial Draft: Tuesday Jan 16, 2007
Last Revised: Monday Feb 12, 2007
Summary
Fedora includes a set of open source Java RPM packages that originate from the JPackage repository (www.jpackage.org). Currently, these packages are marked with a "jpp" tag:
javacc-4.0-3jpp.3.src.rpm
These packages are rebuilt against Fedora's gcc and included in Fedora. They use the "jpp" tag for three main technical reasons:
- to help manage upgrading packages from Fedora to JPackage and back
- to track package hierarchy (this Fedora Java package came from that JPackage Java package)
- to help the Red Hat Java packagers perform grouped operations on all the Java packages
Proposal
Normally, this use of the "jpp" tag would violate the [wiki:Self:Packaging/NamingGuidelines Fedora Package Naming Guidelines] .
In order to reach a compromise, the following guidelines have been drafted:
Managing upgrading packages from Fedora 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 Fedora to JPackage and so forth:
JPackage RPMS have a Release of Xjpp (e.g. 1jpp). Fedora RPMS (which are taken from JPackage) will have a Release that takes the JPackage Release (Xjpp), and appends a subrelease integer (Y) after the jpp tag. This will make the Fedora Java packages have a Release of: Xjpp.Y (e.g. 1jpp.1).
While the Fedora package is in the devel branch, only the subrelease is incremented (e.g. 1jpp.2, 1jpp.3) until a new package from JPackage (e.g 2jpp) is merged into Fedora, at which point, the release would change to match the new JPackage RPM, and the subrelease would reset to 1.
Normally, we'd give the packager the choice of using '%{?dist}' or bumping the release to ensure clean upgrades across Fedora 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. 1jpp.1%{?dist})
Once the Fedora package is out of the devel branch and into a released branch, the release and subrelease fields are frozen. These packages are now subject to the [wiki:Self:NamingGuidelines#DistBump Minor release bumps for old branches] rule.
JPackage | Fedora Package | Status | Highest RPMver |
javacc-4.0-3jpp.src.rpm | javacc-4.0-3jpp.1.fc7.src.rpm | Package merged from JPackage into Fedora devel | Fedora |
javacc-4.0-3jpp.src.rpm | javacc-4.0-3jpp.2.fc7.src.rpm | Fedora package has a bug fixed, bump subrelease | Fedora |
javacc-4.0-3jpp.src.rpm | javacc-4.0-3jpp.3.fc7.src.rpm | Fedora package is rebuilt for new gcc, bump subrel | Fedora |
javacc-4.0-4jpp.src.rpm | javacc-4.0-3jpp.3.fc7.src.rpm | JPackage is updated to fix a bug, bumps major release | JPackage |
javacc-4.0-4jpp.src.rpm | javacc-4.0-4jpp.1.fc7.src.rpm | Fedora package is merged from new JPackage | Fedora |
javacc-5.0-1jpp.src.rpm | javacc-4.0-4jpp.1.fc7.src.rpm | JPackage releases new version of package | JPackage |
javacc-5.0-1jpp.src.rpm | javacc-5.0-1jpp.1.fc7.src.rpm | Fedora package is merged from new JPackage | Fedora |
javacc-5.0-1jpp.src.rpm | javacc-5.0-1jpp.1.fc7.src.rpm | FC-7 is released, package is no longer in devel | Fedora |
javacc-5.0-1jpp.src.rpm | javacc-5.0-1jpp.1.fc7.1.src.rpm | A bug is fixed in the FC-7 package. | Fedora |
This methodology ensures a clean upgrade process. It also ensures that when the "jpp" tag is removed, the upgrade process is unaffected. This is, however, a violation of the naming policy around releases, and is only permitted in this special case exception for Fedora Java packages from JPackage.
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 Fedora, on top of the existing [wiki:Self:Packaging/NamingGuidelines#PreReleasePackages Fedora pre-release guidelines] . Here is an example of a pre-release using the JPackage Subrelease Policy:
JPackage | Fedora Package | Status | Highest RPMver |
javacc-4.0-0.1.a.1jpp.src.rpm | javacc-4.0-0.1.a.1jpp.1.fc7.src.rpm | Package merged from JPackage into Fedora devel | Fedora |
javacc-4.0-0.2.b.1jpp.src.rpm | javacc-4.0-0.1.a.1jpp.1.fc7.src.rpm | JPackage moves to "b" tag | JPackage |
javacc-4.0-0.2.b.1jpp.src.rpm | javacc-4.0-0.2.b.1jpp.1.fc7.src.rpm | Fedora version of "b" tag package | Fedora |
javacc-4.0-0.2.b.2jpp.src.rpm | javacc-4.0-0.2.b.1jpp.1.fc7.src.rpm | JPackage is rebuilt for packaging fix | JPackage |
javacc-4.0-0.2.b.2jpp.src.rpm | javacc-4.0-0.2.b.2jpp.1.fc7.src.rpm | Fedora version of JPackage packaging fix | Fedora |
javacc-4.0-0.2.b.2jpp.src.rpm | javacc-4.0-0.2.b.2jpp.2.fc7.src.rpm | Fedora rebuilds in devel against a new compiler | Fedora |
javacc-4.0-0.2.b.2jpp.src.rpm | javacc-4.0-0.2.b.2jpp.2.fc7.src.rpm | FC-7 is released, package moves out of devel | Fedora |
javacc-4.0-0.2.b.2jpp.src.rpm | javacc-4.0-0.2.b.2jpp.2.fc7.1.src.rpm | A bug is fixed in the FC-7 package. | Fedora |
javacc-4.0-1jpp.src.rpm | javacc-4.0-0.2.b.2jpp.2.fc7.1.src.rpm | JPackage moves to final release (not pre anymore) | JPackage |
javacc-4.0-1jpp.src.rpm | javacc-4.0-1jpp.1.fc7.src.rpm | Fedora version of final package | Fedora |
Track Package Hierarchy From JPackage to Fedora
With the subrelease scheme as documented above, it is very obvious from which JPackage RPM the Fedora Java package originated from.
Help the Red Hat Java Packagers Perform Grouped Operations
The need to perform various grouped operations on sets of packages is not unique to the Java packages, but rather, a problem which many people in the Fedora community are working to solve, through new tools and improvements to existing ones.
One key point to note is that the direction is currently to handle Grouping or Categories of packages with metadata that is not hardcoded into the package itself. Or, to put it simply, to not use the Group:
field in rpm for this task. It is far too inflexible, as packages can (and do) fall under many different groups or categories.
The grouping operations are:
- Being able to query for the set of Java packages installed
- Being able to exclude the Java packages as a group from the yum install/update/remove processes
Until these grouping operations can be performed without the "jpp" tag, there is no other (non-intrusive) way to meet this need.
Query for the set of Java packages
The rpm -qg (or rpm -q --group) command currently does not accept patterns. If it was possible to do 'rpm -qg "Java*"' we could add "Java/" to all "Group:" tags of all Java packages and that would work.
Group Exclude in Yum
yum has already some group functionality (groupinstall, groupupdate, groupremove, groupinfo) that is based on an XML file that is kept in the repository. But the option --exclude only acts on file names, we need a --groupexclude.
There is currently a "Java" group, with only 2 packages on it:
Loading "installonlyn" plugin
Setting up Group Process
Setting up repositories
Group: Java
Description: Support for running programs written in the Java programming language.
Mandatory Packages:
libgcj
java-1.4.2-gcj-compat
We could just make sure all Java packages are in the Java group to make use of the yum group functionality. Enabling a --groupexclude would meet this criteria.
Policy Conditions Defined
Accordingly, Fedora will permit Java packages from JPackage (and ONLY Java packages from JPackage) to use the "jpp" tag, under the following conditions:
- The use of the "jpp" tag is temporary. Once there is no longer a technical need as defined in this document, it will be removed from all Fedora packages.
- Fedora Java packages must follow the subrelease versioning as defined in this document. When the "jpp" tag is removed from Fedora packages, this document will be updated to reflect the change in the subrelease scheme, but the Fedora Java packages will still need to follow it.
- No other packages fall under this policy (at this time).
- Packagers of Fedora Java packages need to explicitly agree to this policy during package review.