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

Jesse Keating jkeating at redhat.com
Fri Jan 12 03:30:34 UTC 2007

On Thursday 11 January 2007 17:49, Fernando Nasser wrote:
> 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.
> "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.

What about cases where we need to rebuild the package internally for a mass 
rebuild, a java change or whatnot?  Especially if it doesn't line up with a 
rebuild upstream, do we just have to convince jpackage to do a spurious 
rebuild?  Otherwise, we're going to bump and build within our CVS, then next 
time you import an srpm from upstream, you'll stomp on any changes we've 

Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20070111/451aa800/attachment.sig>

More information about the Fedora-packaging mailing list