Strange RPM versioning problem in qemu in Rawhide

[Adam Williamson]

On Tue, 2011-08-02 at 21:24 +0200, Michael Schwendt wrote:
> On Tue, 02 Aug 2011 11:58:08 -0700, AW (Adam) wrote:
> 
> > > 0.2.20110718525e3df.fc16
> > > 0.2.2011072859fadcc.fc17
> > > 
> > > Split up into the elements that RPM compares, these are:
> > > 
> > > 0, 2, 20110718525, e,     3,  df, fc, 16
> > > 0, 2, 2011072859,  fadcc, fc, 17
> > >       ^^^^^^^^^^^^
> > > The third elements cause this evr-comparison to have a result which you
> > > don't expect. Bump the second element "2" to "3" and you should be
> > > fine :-).
> > 
> > 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.
> 
> When would that be?
> 
> Packagers ought to bump the most-significant portion of %{release}
> with every build where %{version} stays the same. In this case:
>   0.2.somelongstuff => 0.3.somesimilarlylongstuff

oh, yes, you're right, my mistake. I was mistaking the 0.2 / 0.3 bit for
an upstream version number, but of course it's not that, it's the
'failsafe' revision bump, which does indeed solve this kinda problem. I
think it might still be a good idea to split the date from the git rev,
but since we have the extra revision digit there, it's not really
crucial. I was forgetting about that.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net