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

[Toshio Kuratomi]

On Thu, 2007-01-11 at 17:49 -0500, Fernando Nasser wrote:
> 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.
> 
Sounds good.

>  > 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.
> 
Sounds like a good deal.
 
> 
> 
> "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
> 
Reading this it looks like the packages are now namedSo
name-numericversion-1jpp upstream and name-numericversion-1jpp.2 by
Fedora.  Is that correct?

> d. An initial agreement has been reached to also compatibilize the 
> pre-release cases, with JPackage adopting a Fedora-like order.
> 
Do you have a link to this documentation?  I found this:

http://www.jpackage.org/cgi-bin/viewvc.cgi/*checkout*/src/jpackage-utils/doc/jpackage-1.5-policy.xhtml?root=jpackage&content-type=text%2Fhtml
Which doesn't cover versioning and this:
  http://www.jpackage.org/jpppolicy.php
which says it's the old version and indeed, has the old versioning
information.

>  > 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)
> 
You're not understanding Goal #3.  The goal is to have a mixture of
Fedora and JPackage packages installed on the system.  Running "yum
update" will update to the latest version of the software from the
repository which the current version comes from.  Your (b) and (c) are
for the case where you want to draw your java packages from either
Fedora or JPackage, not both.

Goal #3 could probably be realized with commandline switches if Fedora
did not include jpp in the name: yum update --disablerepo=jpackage
--exclude='*jpp*'; yum update --enablerepo=jpackage '*jpp*'

> 
> 
>     "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.
> 
Can you give a developer use case?  We tried to imagine a use case for
developers and what we came up with was looking in cvs for the package.
At that point, there is no rpm package so there is no release tag.
Giving us a few use cases will help to see what will and won't work.

> 
> 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.
> 
Again, a use case would be nice.  I'm imagining switching between the
jpackage java stack and the Fedora java stack and don't see how *jpp*
would help here.

Unless you mean it makes it easy for you to select all the java packages
on the system and replace them with something else?  That strikes me as
a misuse of the release tag -- 1) Not all java packages will have the
jpp name as not all java packages will come to us through jpackage. 2)
If we do this for java, why not for python, perl, php, etc?

>  > 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.
> 
You're going to have to post the commands you use to achieve these
things as I'm having problems understanding how you're doing this based
on the release tag.

> 
> 
> 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 
> Fedora/Upstream."
> 
> 
>  > 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.
> 
This may be true in the RH-Fedora java group but it won't be true in the
Fedora-community java space unless the mandate from the FTC is to get
packages approved in jpackage before getting them into Fedora.  Not
everything happens upstream.  Not every upstream agrees with the
downstream.  Not every upstream has the same time frame for updates as
downstream.  We will carry local patches and changes at some point.

> 
> 
> "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.
> 
No.  cryptix-asn1 is an example.  It doesn't matter if the specific
package has been fixed.
The question's contained here are:
1) What are jpackage's naming guidelines so we can see how they mesh
with our names?
2) If there's a bug with the jpackage naming what will we do until it's
fixed?
3) Do we want to force our packagers and reviewers to learn two sets of
guidelines, one for jpackage, and one for Fedora?

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

You're right.  Remove the jpp from Fedora package release tags and we
should be able to do this :-)  Seriously, the goal is to have "yum
update" just work, so even with jpp removed, we can't achieve this.

> 
> "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.
> 
Ain't that the truth!  We have to do this for the entire distro.  That's
a bit besides the point.

>  > 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.
> 
This is where we have divergence.  You claim that all fixes go upstream
first.  I claim that 1) this won't continue to be the case (all fixes)
and 2) it may not be desirable.   Example: There's a showstopper bug in
a java package just before F7 is spun.  The jpackage maintainer doesn't
think it's a showstopper or would rather wait for upstream to fix it
before committing a patch.  We aren't going to hold F7 for it so we have
to fix it locally.  Example: jpackage upgrades to a beta version of a
component while we want to stay on the stable release or vice versa.

>  > 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.
> 
Not true.  Jesse Keating proposed a naming scheme which would work
equally well.

> 
> 
> "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 
> release.
> 
What are you looking for inside the package repos?  What is your rpm -qa
|grep jpp used for?  The comment above was from the projected usage case
of a developer needing to look at a package in the cvs repository to
decide what version a package was built against.  In that case, you
would need to look inside the spec.  Help us understand what you're
doing so we can see where the other proposals fail.

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

There's all manner of odd things in Provides.
 Provides: jpackage(foo) = 1.0-1jpp
Would fit right in :-)

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/packaging/attachments/20070111/70f22887/attachment.bin