[Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals
Tom 'spot' Callaway
tcallawa at redhat.com
Fri Jan 12 22:01:36 UTC 2007
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
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
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.
More information about the Fedora-packaging