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