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 <jden...@redhat.com>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
