[Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals

Fernando Nasser fnasser at redhat.com
Thu Jan 11 22:49:39 UTC 2007

Hi all,

At Jesse's request, I took a look at the Wiki page in


"Naming Conventions for Packages Adapted from JPackage"

Of course, some time has passed and things have already evolved, so I 
will try and update the text.  Please comment and lets see how we should 
update the Wiki page.

1) Problem Space

"Many Java programs are first packaged by the [WWW] 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."

 > Well, The last sentence is no longer true.  The AOT compilation bits 
were propagated upstream, so all the Java team has to do now is to 
import the upstram package as is and build.  We still need to make any 
changes to the code to circumvent GCJ shortcomes, but these are so rare 
nowadays that almost all packages build without any changes at all.

 > As a consequence, fixes have been made on the usptream version, which 
is them re-imported, and we've been also reimporting when fixes are 
applied upstream comming from the other JPackage-based distros or from 
direct JPackage users feedback.

"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:"

 > OK, here we have made much progress:

a. The "_" character has been removed and replaced by a '.'

b. The "fc" string has been removed

c. All FC6 packages have been rebuilt to comply with a and b above

d. An initial agreement has been reached to also compatibilize the 
pre-release cases, with JPackage adopting a Fedora-like order.

 > Summary: It all comes down now to the remaining ".NNjpp" in the 
release which indicates the upstream version that was last imported 
(sync point you could call it).

In the case of the goals, I think the original ones in the week were not 
  correct in the first place.  Lets try again:

"   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]

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

 > These two goals can be made into a single one, lets say: "flexible 
upgrade paths".

 > There is no conflict whatsoever -- we currently do all these:

a. Both Fedora and JPackage (what is stated in 1, i.e., newest release 
globally) by leaving all repos enabled (both fedora-core and jpackage)

b. Fedora only by disabling the jpackage.repo

c. JPackage only by using --exclude=*jpp* --excluce=eclipse* when 
upgrading from fedora-core.repo and enabling only the jpackage.repo for 
the Java packages update (people play with --enablerepo for that management)

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

 > This is very important to us (Java team).  We can quickly identify if 
the version we have already has a fix or not, among other things.

I will have to add a goal that was not stated in the initial Wiki, lets 
call it 4:

   "4.  Allow the switching of Java stacks as a whole"

 > This is currently accomplished by using regular expressions based on 
the *jpp* and eclipse* patterns.

 > This is useful for development so we can try sets of packages built 
with a different compiler for instance, without having to change all 
spec files to bump releases, and to revert the system to the original 
state afterwards.  We use this a lot.

 > There are also users that want to switch the collection of Java 
packages  to use a set compiled with a proprietary JDK for instance 
(maybe a different version of Java), or something provided by the 
software vendor of some major component they bought.

OK, now the Wiki page states:

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

 > Which I think is correct.

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 [WWW] here although he 
phrases it in the specifics of Fedora/JPackage instead of the general 

 > We don't do anything to make packages run better on Fedora.  We do 
pre-compilation, which does help in the startup time.  But there is no 
real harm in revert to a bytecode-only package to get an upstream fix 
until it shows up in pre-compiled form in a Fedora update.

"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."

 > That was a wrongly versioned package from an older JPackage release. 
  The maintainer was informed and the problem was fixed.  It is now 
cryptix-3.2.0-9jpp.  In general, we have had no problems in getting this 
kind of things fixed.  I think this comment can be removed.

"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."

 > Yes it is implementable, as shown above.

"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."

 > Putting a set of compatible packages together is a major endeavor. 
The Java team, as well as the folks from Mandriva and Suse have been 
basically polishing the sets that have been created upstream.

 > Also, we make the fixes/changes upstream first, then import.  This 
way we benefit from feedback from people (both packages and Java users) 
who know deeply some of these Java software libraries.

 > Again: updating paths are optional, and it is up to the user to 
choose.  The current naming only allows that to be done if so desired, 
which would be otherwise not possible.

"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."

 > The way we do now is by "rpm -qa | grep jpp" and variations.  Or 
similar pattern usage in the repos.  We don't need to look inside the 
spec file to know that the base for that release was a specific upstream 

 > Using things like "Provides" for things that are not their original 
goal would be abusing that feature, and the information for that is used 
by depsolvers and such.  We should stay away from that.  In a lesser 
degree, maintaining a release in the description is not convenient and 
error prone, and does not address the other goals anyway.

The Wiki page then has some proposals, which I would prefer to discuss 
each one separately once we agree on the goals.

Regards to all,

More information about the Fedora-packaging mailing list