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
Tom 'spot' Callaway wrote:
On Fri, 2007-01-12 at 14:03 -0500, Jesse Keating wrote:
>On Friday 12 January 2007 11:48, Fernando Nasser wrote:
>>Yes, we have the changelog entries added for the respin everything
>>cases, some old entries regarding changes that were made for GCJ
>>compilation when it was not as perfect as it is today, some emergency
>>local fixes doen during release times that were incorporated upstream a
>>few days later. If this is deemed not important we can stopp merging them.
>>We will still add our '.N' release number to the release tag and add a
>>changelog entry saying that we have imported and are rebuilding it with
>>BTW, so far we had to remove the Vendor and Distribution tags from the
>>upstream spec file too, but that has been removed upstream to make it
>>easier for the distros to import the packages.
>I think adopting a work method that doesn't stomp local changes is very
>important, including adding an entry about importing from upstream for the
>I still don't like "jpp" being there, however I suppose I can live with
>provided others on the packaging committee can too, and we create a special
>case for it (ICK).
I really don't like it. To be blunt, the arguments for keeping it seem
to be "Because we waaaaaaaant it."
It really doesn't serve a useful purpose. Release should be for tagging
the build number of a package, with the exception of the dist tag, which
identifies the distribution that a package is built for. "jpp" is
irrelevant in both contexts, as these are Fedora packages, in a Fedora
Fedora-packaging mailing list