On Wed, 2012-06-13 at 13:22 -0700, Adam Williamson wrote:
On Wed, 2012-06-13 at 20:10 +0200, Pierre-Yves Chibon wrote:
On Wed, 2012-06-13 at 11:45 -0600, Pete Zaitcev wrote:
On Mon, 23 Apr 2012 14:08:05 -0600 Orion Poplawski orion@cora.nwra.com wrote:
%global commit bd245c9
Source0:
https://github.com/jukka/pcfi/tarball/%%7Bcommit%7D/jukka-pcfi-%%7Bcommit%7D...
%setup -q -n jukka-pcfi-%{commit}
I do not understand how this is supposed to work in the face of "yum update".
But if you read his email carefully, Orion isn't speaking about the version. So commit will be bd245c9 but the version might very well be
Version: 20120613git%{commit}
and as long as the date gets updated, yum will be happy with it.
The guidelines actually require an integer before the date/rcs rev part, which should be incremented at every build. Like so:
1.20110102git9e88d7e 2.20110102git9e88d7e 3.20120201git8fg34f6 4.20120201git8fg34f6
It doesn't get reset when you bump the snapshot, to double-plus-ensure that no mess in the snapshot bit of the tag can ever cause problems.
Erf. I forgot that if it's a pre-release snapshot, you make it %{version}-0.X.%{snapshot} .
The rules are a bit complex :) but all make sense, and if you follow them, you should never get in trouble with updates not superseding. You should _always_ include a version, even if it has to be notional, and if it's notional, do everything you can to make sure it's lower than any possible version number upstream might actually release in future. Always include X (post-release) or 0.X (pre-release, so that the first actual release build can always be 1) before the snapshot bit, whatever snapshot naming format you're using.
There are some good examples given on the page right under 'Pre-Release packages', it's worth looking at those.