Manipulate Dev. release number properly

Paul Howarth paul at city-fan.org
Wed Feb 23 09:31:04 UTC 2011


On 23/02/11 02:21, Robin 'cheese' Lee wrote:
> Hi!
>
> RPM doen't generate proper version numbers for Dev. releases of modules. For
> example, perl(CPAN) of f14 is actually 1.94_56 which just means 1.9456. But
> the version generated by RPM is 1.94, much smaller than the actual version.
> So I hope RPM can manipulate the underscores in version numbers properly.

perl module version numbers are usually real decimal numbers rather than 
the hierarchical version numbers that are mostly used elsewhere and by 
rpm. So for instance a perl module version 5.2 would be newer than its 
5.15 version but rpm would think that 5.15 was newer than 5.2. So 
underscores are not the only things to worry about with perl version 
numbers.

It sometimes makes sense to separate the rpm and upstream version 
numbers so that the rpm upgrade path is maintained. The tidiest way is 
probably to pick a number of decimal places to use and stick with that 
for all rpm versions, and if upstream does a release where your chosen 
number of decimal places would result in the same rpm version number, 
just bump the rpm release instead. The alternative is to bump epoch 
whenever necessary to maintain the upgrade path when using the upstream 
version numbering scheme.

We generally try to avoid packaging dev/trial versions of perl modules, 
so the underscore issue doesn't come up that often, but sometimes it's 
necessary. I doubt that rpm is likely to change its treatment of 
underscores so I think you just need to take care with versioning just 
as is necessary with other aspects of perl module versioning (including 
versioning of perl(...) provides, which have the same issues as the perl 
modules themselves).

Paul.



More information about the perl-devel mailing list