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. -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
