Summary of the 2008-04-08 Packaging Committee meeting

Michael Schwendt mschwendt at gmail.com
Wed May 14 13:54:27 UTC 2008


On Tue, 13 May 2008 13:38:51 -0700, Toshio Kuratomi wrote:

> Jason Corley wrote:
> >> Nicolas, I believe you're wrong. I can't find a single revision by devrim that syncs from the JPackage spec[1]_ to the Fedora spec.
> > 
> > Yes if you focus only on the current maintainer's history of
> > collaboration with JPackage you won't find any.  However the following
> > shows what used to happen:
> > 
> I don't dispute that.  But I am saying that a new maintainer took over 
> the package.  So there was no history of sharing changes with JPackage 
> there.  Continuity doesn't follow the package because there is no policy 
> or guideline that says that java packages have a special relationship 
> with JPackage.  the maintainer was just following the best practices 
> that they had established by working on other packages in Fedora.
> 
> Fedora is a community of packagers.  Those packagers have different 
> styles of packaging and working.  Where we need to, we unite those 
> styles with Packaging Guidelines and FESCo Policies.  Until we have a 
> policy that specifies that certain classes of packages must use JPackage 
> as upstream this kind of thing will happen as packages go through 
> different maintainers.

In addition to my earlier comment:

http://fedoraproject.org/wiki/Packaging/JPackagePolicy

[...]

Fedora includes a set of open source Java RPM packages that originate
from the JPackage repository (www.jpackage.org). Currently, these
packages are marked with a "jpp" tag:

javacc-4.0-3jpp.3.src.rpm

These packages are rebuilt against Fedora's gcc and included in Fedora. They use the "jpp" tag for three main technical reasons:

    * to help manage upgrading packages from Fedora to JPackage and back

    * to track package hierarchy (this Fedora Java package came from that
      JPackage Java package) 

-snip-

You break with these two "main technical reasons" if you put "jpp" in
the evr only for the third technical reason (i.e. "group operations").




More information about the devel mailing list