From Fedora Project Wiki

This page discusses the reasons for keeping the "jpp" substring in release tags for Java packages that have been imported from JPackage

There are two main questions.. "why" it is needed? And "how" is it used?

Short answer:

- Why: The substring is needed to allow existence of separate stacks of common packages
- How: It is used for grouping operations (ie. exclude='*jpp*' in yum.conf)

Long answer:

  • Removing "jpp" hurts JPackage developers who wish to develop on Fedora and need to have a complete JPackage stack on their system
  • For this purpose, they need to be able to exclude '*jpp*' in fedora.repo since grouping operations are not possible at this time
  • Removing "jpp" makes Fedora a non-starter OS for JPackage, as they cannot use Fedora as their development OS (see above)
  • Removing "jpp" hurts people wishing to deploy an entire JPackage stack (much larger than the Fedora Java stack)
  • Currently, most of the Fedora Java stack consists of direct and indirect dependencies of other packages (ex. Eclipse, Tomcat) rather than consisting of packages that users want to make use of (ex. in JPackage: axis2, netbeans, excalibur*, hibernate3, JBoss, jetty6). As a result, there is a legitimate need for users to want to use JPackage stack in its entirety for consistency and testing purposes
  • All of JPackage going into Fedora would mitigate this problem but is not realistic at this time given the lack of Java developers in Fedora
  • "jpp" gives credit to original package authors at JPackage
  • Grouping by '*jpp*' is currently the only way to separate JPackage based packages on a Fedora machine. Being able to tell if a package in Fedora came from JPackage would allow JPackage contributors to be able to merge changes that were done after the Fedora import, back into JPackage

Note: The need to perform various grouped operations on sets of packages is not unique to the Java packages, but rather, a problem which many people in the Fedora community are working to solve, through new tools and improvements to existing ones. As was previously agreed upon, when these tools exist, this "jpp" decision will be revisited