[Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals
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
> > 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
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Fedora-packaging