[Fedora-packaging] Re: Guidelines and epochs

Michael Schwendt bugs.michael at gmx.net
Mon Jan 8 17:22:35 UTC 2007


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
> particular.

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
upgrade attempt:
  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,
  foo-devel-1:1.1-1.i386.rpm
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.




More information about the Fedora-packaging mailing list