spec file changes: removing Release: and %changelog

[Tom "spot" Callaway]

On Wed, 2008-03-05 at 09:34 -0900, Jeff Spaleta wrote:
> On Wed, Mar 5, 2008 at 9:28 AM, Colin Walters <walters at redhat.com> wrote:
> >  The overall idea is that the release number is determined by the "build
> >  server", where "build server" can be either localhost (for make local),
> >  or Koji (for Fedora).  So for local builds, you don't hit Koji to
> >  determine a release - we just create one, and then increment it from
> >  there.
> >
> >  We don't want to distribute locally-built RPMs as if they came from
> >  Fedora, so giving them a .local disttag with a locally-determined
> >  release is a good thing, I think.
> 
> I think you have to abstract this a little and rely on a increment
> counter macro in the release field to give maintainers the option of
> using(or not) and potentially overriding.  That way maintainers can
> encode the integer counter into the Release field in a way that makes
> sense to keep the update path working...even for wacky 'edge' cases
> like the kernel.

There is some merit in this, but its not as easy as it seems.

Say that we have a %{counter} variable that gets magically incremented
based on the build, this better handles the edge cases, but what about
when we update to a newer version? 

Foo goes from 1.0.1 to 1.0.2. The Release should reset to 1. The
%{counter} needs to know this (while incrementing it forever is
possible, its ugly) and do the right thing.

~spot