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