spec file changes: removing Release: and %changelog
Colin Walters
walters at redhat.com
Wed Mar 5 18:42:46 UTC 2008
On Wed, 2008-03-05 at 13:34 -0500, Jesse Keating wrote:
> On Wed, 2008-03-05 at 13:28 -0500, Colin Walters 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.
>
> But again, why is it by the build server? You want to match the changes
> to the spec with a number usually, even if that number doesn't get
> built, or doesn't get successfully built. This is why the kernel used
> to key the release from the cvs check in number. Of course that ran
> afoul of branch collisions.
I see three options, in increasing complexity:
First, Koji could keep a mapping from its made-up Release integer to the
CVS commit tag.
Second, we could use some transformation of the CVS commit tag as the
Release.
Third, we could switch to a revision control system with
* Atomic commits
* A nice integer sequence mapping for commits on a branch
Subversion and Mercurial both have these properties; I'm not sure if git
has the second.
More information about the devel
mailing list