[Freeipa-devel] git versions for rpms in makefile

[John Dennis]

On 03/26/2013 10:41 PM, 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.
>>
>> Simo.
>
> 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:
>
> 3.1.99-1.GIT5acd43d.fc18.src.rpm
>
> which would have been newer than
>
> 3.1.99-0.GITec94138.fc18.src.rpm
>
> 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 think you're confusing issues. You cannot use a git hash to properly 
collate based on build sequence. This is why in our development builds 
we prefix the git hash with a timestamp. It's the timestamp which 
affords the proper collation, the git hash is only informative. These 
issues to not arise in "release builds" because version and or release 
value is incremented.

But the above is independent of whether we should follow the fedora 
convention for git hash, that's probably a good idea, just realize it 
won't solve your problem of version collation.


-- 
John Dennis <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/