On Mon, 8 Jan 2007 17:37:10 +0100 (CET), Nicolas Mailhot wrote:
Le Lun 8 janvier 2007 17:09, Axel Thimm a écrit :
> On Mon, Jan 08, 2007 at 11:03:54AM -0500, Fernando Nasser wrote:
>> Axel, 1.10 wins over 1.09. Why do you need an Epoch in this case?
> Sorry, I meant 1.1 vs 1.09.
Then the best practice would be to write 1.1 1.10 (I hope this is
documented somewhere). Tought of course it would be better if upstream
used a fixed digit number, but some developpers have been known to take
this suggestion as a pretext to rant on Red Hat in general, and rpm in
Rollback with Epoch bump and an incompatible versioning scheme chosen by
upstream are two different problems.
Upstream developers can be educated as soon as they increment their
numbers in bad ways. Don't assume a worst case.
And even if they were stubborn enough to stick to an incompatible
versioning scheme that breaks RPM version comparison, "Provides" could
work around the incompatible increase (e.g. with 1.09 => "1.1 = 1.10")
or even be deleted to break dependencies deliberately:
foo-devel-1.09-1.i386.rpm provides foo(api) = 1.09
foo-devel-1.1-1.i386.rpm ... ooops! 1.1 < 1.09 ... now what?
Anything which does BR foo(api) >= 1.09 would fail already.
Epoch bump makes RPM upgrade possible at least,
and what to provide? A possibly fragile foo(api) = 1.10 where
1.1=1.10? Or maybe a new API like foo(api.2) = 1.1?
The same is not possible with the fully automatic %name = E:VR Provides.