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.
Permaine
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
AOT.
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
build.
I still don't like "jpp" being there, however I suppose I can live with it,
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
repository.
~spot
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
