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