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@xxxxxxxxxx nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
