On Fri, 2007-01-12 at 15:57 -0500, Permaine Cheung wrote: > Suppose we have a packaging issue (e.g. file not placed in a proper > location) in java-foo-1.0-1jpp, which it's fixed in java-foo-1.0-2jpp, > without the jpp release info, we won't be able to tell if that affects > our java-foo package or not. If the jpp version is not kept in the > package name, then we may have to spend more time on investigating > problems arised from other packages depending on java-foo-1.0-1jpp. On > the other hand, if we know our package is 1jpp version behind, we could > have tried updating java-foo in the first place and solve the problem > faster. To be fair, since jpp only updates release by integer increments (1, 2, 3, etc) and fedora permits subreleases (1.1, 1.2), you could simply look at the release field to determine ordering and hierarchy. Say you have java-foo-1.0-1.1 in Fedora, and you fix a bug in java-foo-1.0-2jpp, then java-foo-1.0-2jpp is newer, and you know the Fedora package (1.0-1.1) is derived from the 1jpp release. As Fedora makes changes (as needed), they only bump the subrevision (1.2, 1.3, so on). I've spoken to Fernando, and he pointed out some uses for the jpp tag which had not previously been raised (or at least, I missed them, and I don't see them listed in Toshio's document): The Red Hat Java folks are also using the jpp tag to help manage merging packages from JPackage into Fedora. It makes it much easier for them to key off that tag for mass rebuilds, set manipulation, selecting update patterns, etc. This is something that would fall under grouping functionality, they're trying to work around limitations in our packaging infrastructure that exist today. If we had grouping functionality, then they really wouldn't need the jpp tag. They could use that functionality to do their tasks instead of relying on the tag. So, here is my thought process: Long term: Do package grouping/categories in a sane manner, something not embedded in each package. When we have achieved that, drop the jpp tags from these packages. Short term: Recognize that the Fedora java packages are really a repo within a repo (imports from jpp). A big part of this is adhering to the versioning scheme that I described above, where jpp only does integer releases (1, 2, 3), and the Fedora packages derived from those JPP packages add a subrelease (1.1, 2.1, 3.1). This way, when we have the grouping issues managed, we can drop the jpp tag and still have clean upgrades between repos and a clear hierarchy (this Fedora package came from that jpp package). The Fedora packages would only ever increment the subrelease. This is permitted by the current guidelines. Given that we cannot solve the grouping issues currently, I think now we can make a special exception for the jpp packages (and ONLY the jpp packages), where they can continue to use the jpp tag in Fedora until we solve the grouping problem. When we have a workable alternative, then we will drop the jpp tag from use in Fedora. Thoughts? ~spot -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
