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
Attachment:
pgpwV5JfmgRlI.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
