spec file changes: removing Release: and %changelog

Colin Walters walters at redhat.com
Wed Mar 5 18:46:24 UTC 2008


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.

My thought on this is that you can only switch to the new system after a
new upstream release.  That avoids the issue of backwards compatibility
mappings, because the new upstream version will override any previous
Release tags.

I don't know what's special about the kernel - can someone needs to
explain to me what need it has that wouldn't be met by this system?




More information about the fedora-devel-list mailing list