Orion Poplawski wrote:
On 03/26/2013 07:36 PM, Simo Sorce wrote:
On Tue, 2013-03-26 at 19:14 -0400, Rob Crittenden wrote:
Orion Poplawski wrote:
This patch uses the Fedora standard for git versioning
(version-#.git<tag>) when making rpms.  I'm afraid I haven't been able
to test for the non-git version case.

What is the purpose of this? We don't do upstream releases from
developer build, so having the wrong Source0 doesn't seem like a big
deal (though I'll admit no strictly correct).

Sound like a reasonable improvement to me, and makes it sure you do not
confuse an upstream build with a developer build, I am not so sure about
using __GIT__, it's kinda annoying to type, although shell completion
here helps I guess.

I lean toward acking this approach, if you do not have objections Rob.


My motivation for this was from testing the pkcs12 patches.  First I did
an srpm build and got 3.1.99GITec94138-0.fc18.src.rpm.  Then I updated
the git repo, did another srpm build and got
3.1.99GIT5acd43d-1.fc18.src.rpm which would have been lower EVR wise.
Now I can get:


which would have been newer than


and allowed me to do yum update.

(actually, for pre-releases it should be -0.1.GIT, -0.2.GIT, ...)

So it doesn't impact releases, just local developer testing - which I
don't know how much is done via rpms.

I also wouldn't expect you would ever have to type __GIT__, why do think
you would?  That is just in the spec.in and gets substituted out for the

The root of the problem is the release in n-v-r is always the same value in builds because it makes no difference in a developer build. So either this patch needs to go farther and generate a real value for RELEASE or it just shifts the problem.

For pre-releases you build with IPA_VERSION_IS_GIT_SNAPSHOT=no and the values from the file VERSION are used.

I generally build and develop on the same machine so a repo never comes into play and use rpm --force -Uvh dist/rpms/* to update.


Freeipa-devel mailing list

Reply via email to