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

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