On 10/07/09 16:33 +0100, Nigel Horne wrote:
> Are there other CPAN modules with the same bug?
plenty of them. i encounter this problem regularly since i package perl
modules for mandriva. (around 700 at the time of writing)
i'm generally opening a bug on rt (see the bugs i opened), which is
fixed or ignored depending on the author. note that even the great & old
ones can be confused by this: damian (yup, the damian) made the same
mistake for parse::recdescent. :-)
this is why i'm now using a macro in rpm generation to force the
rpm package version to a x.y.z
here's the macro fyi:
perl -Mversion -le '
$x = "%{1}";
$y = $x;
$x =~ s/[[:alpha:]]*$//;
$y =~ s/^$x//;
$x =~ s/\D*$//;
$v = version->new($x)->normal;
$v =~ s/^v//;
print "$v$y";'
this macro changes the version from 1.6 to 1.600.0, and 1.6.0 to 1.6.0
advantages are twofold:
- it's pretty obvious why a module doesn't get updated
- it does not confuse the heck of rpm, which doesn't know as well as
perl how versions work in cpan
the drawback is that the rpm package version does not always match the
real version. but that's just a packaging drawback, which is not that
big a problem since it doesn't change the runtime.
see http://jquelin.blogspot.com/2009/05/rationalizing-perl-module-versions.html
btw. this is not the only version problem encountered when dealing with
cpan modules. i think the "best" one i got is the guy who used ddmmyyyy
as a version scheme! :-)
jérôme, sick of versions
--
jque...@gmail.com
