Strange RPM versioning problem in qemu in Rawhide

[Nils Philippsen]

On Tue, 2011-08-02 at 12:12 -0700, Adam Williamson wrote:
> On Tue, 2011-08-02 at 11:58 -0700, Adam Williamson wrote:
> 
> > Well, in this case yes, but this problem could emerge again in a case
> > where there's no version bump that 'should have' been carried out. The
> > fundamental problem here is that git commit IDs are a single hex string,
> > but RPM version comparison doesn't do hex, it splits out base-10
> > 'numeric' fields and 'alphabetic' fields.
> 
> I suppose also, of course, git commit IDs don't increment, so even if
> RPM spoke hex, they'd be unsuitable for use in version comparison. I
> don't know if anyone would argue it's fundamentally 'wrong' for git
> commit IDs to be in RPM EVRs, or if it's okay for them to be there as
> long as you make sure there's stuff ahead of them which will always
> compare correctly. Maybe the RPM team has an opinion.

As the part before date/git-hash should have been incremented, I see
date and git hash only as being informative to the people dealing with
the package and not relevant for correct version comparison. The only
issue I see is with the dist tag being after it... Everything else (of
relevance) being the same, we do want .fc17 packages to trump over .fc16
packages always, don't we?

So rather than the existing release scheme ...

["0"-if-prerelease.]N[.date-scm or "snap"[.snapshot-revision]][.disttag]

... I'd order it most-to-least-significant regarding version comparison:

["0"-if-prerelease.]N[.disttag][.date-scm or "snap"[.snapshot-revision]]

Nils
-- 
Nils Philippsen      "Those who would give up Essential Liberty to purchase 
Red Hat               a little Temporary Safety, deserve neither Liberty
nils at redhat.com       nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:      C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011