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