Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
October 24, 2010, 1:21 pm
rate this thread
Fedora 13 does not have the Net::TFTP module in their repositories, so I
am using cpanspec to try to build a rpm module. I follow the
instructions on http://fedoraproject.org/wiki/Perl/cpanspec
I then run this:
Fetching Net-TFTP-0.18.tar.gz from
Trying to fetch description from Net-TFTP-0.18/TFTP.pm...
Building source rpm from perl-Net-TFTP.spec
So I get a source rpm file. When I try to rebuild it:
$ rpmbuild --rebuild perl-Net-TFTP-0.18-1.fc13.src.rpm
error: Failed build dependencies:
perl(Test::More) >= 0.8701 is needed by
But the Test::More version is bigger than that:
$ perl -MTest::More\ 9999
Test::More version 9999 required--this is only version 0.94.
BEGIN failed--compilation aborted.
Any idea why?
Re: problem packaging Net::TFTP for fedora 13 amd64
The versioning schemes of RPM and Perl are incompatible. Perl version
numbers are simple floating point numbers, so 0.94 > 0.8701. But RPM
version numbers consist of segments which are compared indvidually from
left to right. Since 0 = 0 and 94 < 8701, 0.94 is less than 0.8701.
This means that when packaging Perl modules as RPMs, one may have to
adjust the number of digits in version numbers. If there was a version
0.8701 and the new version is 0.94, it must be written as 0.9400 to be
larger than the old version. Or you could change the dependency in the
.spec file from 0.8701 to 0.87.01 so that it is less than 0.94.
In any case you have to inspect the version numbers of the RPM packages
not the Perl modules, to see what scheme is used by Fedora.
version numbers (was: problem packaging Net::TFTP for fedora 13 amd64)
I left out v-strings, since I think they weren't relevant to the OP's
In the case of Test::More (and many other modules on CPAN), v-strings
also don't capture the intent of the author. If you have two version
numbers like "0.8701" and "0.94", I think it is clear that the author
intended that to mean "version 0, subversion 87, subsubversion 1" and
"version 0, subversion 94", respectively. But 0.8701 is equivalent to
v0.870.100 and 0.94 is equivalent to v.940.0. Fortunately, for
comparison purposes, it doesn't make any difference.
BTW, there's an error in perldoc version. It says (at least until
$v1 = version->parse("v0.95.0");
$bool = $v1 < 0.96; # FALSE since 0.96 is v0.960.0
The comment should read "TRUE since 0.96 is v0.960.0", but of course
that isn't surprising. A better example would be
$v1 = version->parse("v0.97.0");
$bool = $v1 < 0.96; # TRUE since 0.96 is v0.960.0
I know about v-strings, the _ convention for alpha versions on CPAN,
etc. But so far it hasn't caused me any trouble.
Re: version numbers (was: problem packaging Net::TFTP for fedora 13 amd64)
Yes, especially since the latter is usually written "0.87_01".
Well, only according to version.pm (and, since version.pm is core since
5.10, UNIVERSAL->VERSION). In 5.8 vstrings were just that, strings, and
weren't convertable to numbers at all.
Yup, and this is just one of the cases where version.pm ends up doing
*incorrect* comparisons. If a module says
our $VERSION = version->new("v0.97.7");
and I ask for
use Module 0.96;
I would expect that to succeed, but of course it doesn't.
vstrings (in their 5.6 form) don't exist any more. Instead we have
version objects, which do a whole lot of highly complicated stuff to
ensure they can... not compare versions quite right. In particular,
designing the system so that '0.1234' is '0.123.4' when most CPAN
modules use it to mean '0.12.34' was rather stupid. I also have yet to
find a way to get a $VERSION that stringifies as something with a _ in,
*and* compares correctly to the versions either side without a _,
without resorting to
our $XS_VERSION = our $VERSION = "0.12_01";
$VERSION = eval $VERSION;
and relying on EUMM sticking to its documented hacks.