The frysk RPM version and release strings don't comply with (my interpretation of (?)) the naming guidelines: 0.0.1.2008.02.29.rh1-1 http://fedoraproject.org/wiki/Packaging/NamingGuidelines#PreReleasePackages Assuming that version 0.0.1 is pending, this means that the frysk _version_ should be "0.0.1" and the _release_ should be "0.x.YYYYMMDDgitZZZZ" (an abbreviated git hash, < 13 'Z's). In this case, we'd have: version="0.0.1" release="0.1.20080229git<whatever the hash is>". If patches were made later to this snapshot RPM, the 'x' component of the release would increment by 1 each time. The ".%{?dist}" may be tacked onto the end if you wish. Further snapshots would restart at 1 with the appropriate date and git hash: 0.0.1-0.1.20080229git<whatever the hash is> (existing package) 0.0.1-0.2.20080229git<whatever the hash is> (patch or something to existing) 0.0.1-0.1.20080324git<whatever the hash is> (new snapshot) 0.0.1-1 (actual 0.0.1 release) 0.0.1-2 (patch to 0.0.1 release) ... 1.0-1 (1.0 release) *However*, because the existing version is incorrect, changing it to meet the guidelines will result in all future RPMs being "older" in rpm parlance than the existing one. There are two ways to fix this: 1) add an epoch and 2) make the version "0.0.2". Choice #2 is much preferred, but I guess it sort of depends upon whether or not upstream has released 0.0.1 yet ... or if the "next" (which could be the first) release upstream will be 0.0.2.
Created attachment 296739 [details] potential patch
The frysk tarball is: frysk-0.0.1.2008.02.29.rh1.tar.bz2 and the full version number branded into the executable is: $ ftrace --version 0.0.1.2008.02.29.rh1 there's a balance here between fedora an its deals and frysk's realities. The current system is clearly not causing problems. I trust we can see through to some sort of sane compromise.
That's an interesting version number for the upstream tarball :) If that's what it is, that's what it is, though.