[Fedora-packaging] Re: Guidelines and epochs

[Axel Thimm]

On Mon, Jan 08, 2007 at 05:37:10PM +0100, 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

You mean writing instead of 1.1 the version 1.10? Even if this would
save the day for this package there are other worse examples coming
from the perl world mostly, e.g. 1.00001 vs 1.0000000009 to exaggerate
a bit. perl itself had some awkward versioning like the above.

> (I hope this is documented somewhere).

You mean the "remove all left-padding zeros" stuff? Perhaps it is by
now, maybe in online book by E. Johnson (or better said the draft of
it), but in general it is usually easier to browse through in
rpmvercmp's sources. There's where one can also find that
(technically) epochs are treated like versions for a couple of years
now.

[Previously they were really restricted to integers, who knows why
 this was changed, obviously there is a distro somewhere in need of
 non-integer epochs, or this is one of the unneeded extensions rpm got
 over the years w/o anyone realy needing it]

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

Yep, upstream sometimes isn't glad to get well-meant recommendations
for how to version their babies, not even if it's being emphasized
that non-rpm packaging systems would benefit, too. But it feels like
the number of such adversaries is going down.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20070108/ee15bff5/attachment.sig>