We can use the v-string feature provided by Perl itself to normalize the version numbers of CPAN module rpms. We always convert the legacy decimal versions to normalized v-string, and use the v-string number as the rpm version, since v-string is friendly with rpm and also works within the Perl world. We can get a normalized v-string like this: Perl> require version; 1 Perl> version->parse(1.94_56)->normal v1.945.600 So the rpm version of perl(CPAN) should be 1.945.600 , and the one of perl(Moose) should be 1.120 . And we can even enhance rpmbuild, so when we deal with unstable CPAN modules, we can tell it to keep or discard the numbers after the underscore in specfiles. Or we can think out a more sophisticated guideline for versioning rpms of unstable CPAN modules. Cheers. Robin On Wed, Feb 23, 2011 at 5:31 PM, Paul Howarth <paul@xxxxxxxxxxxx> wrote: > 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. > -- > Fedora Extras Perl SIG > http://www.fedoraproject.org/wiki/Extras/SIGs/Perl > perl-devel mailing list > perl-devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/perl-devel > -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/perl-devel
