configtest.pl not properly recognizing installed version of Crypt::CBC on

[Ryan Delany]

RPM Query output:

rpm -qa | grep CBC perl-Crypt-CBC-2.22-1.el4.rf

configtest.pl output

Crypt::CBC : 2.17 : UPGRADE RECOMMENDED (minimum version 2.22)

I'm guessing since I installed Crypt::CBC as an RPM from Dag's repo, it must not have updated some directory on my machine (so whatever configtest.pl is querying isn't updated properly)

Output from cpan:

cpan> i Crypt::CBC CPAN: Storable loaded ok Going to read /root/.cpan/Metadata

Database was generated on Fri, 05 Jan 2007 11:24:56 GMT

Strange distribution name [Crypt::CBC] CPAN: LWP::UserAgent? loaded ok Fetching with LWP:

​http://www.perl.org/CPAN/authors/id/L/LD/LDS/CHECKSUMS

Module id = Crypt::CBC

DESCRIPTION Cipherblock chaining for Crypt::DES/IDEA CPAN_USERID LDS (Lincoln D. Stein <lstein@…>) CPAN_VERSION 2.22 CPAN_FILE L/LD/LDS/Crypt-CBC-2.22.tar.gz UPLOAD_DATE 2006-10-29 DSLIP_STATUS MdpOp? (mature,developer,perl,object-oriented,Standard-

Perl)

MANPAGE Crypt::CBC - Encrypt Data with Cipher Block Chaining Mode INST_FILE /usr/lib/perl5/site_perl/5.8.5/Crypt/CBC.pm INST_VERSION 2.17

Not sure what sets the INST_VERSION, but it seems like that is what configtest.pl is looking for.

[anonymous]

I did an install Crypt::CBC in cpan and now everything works correctly.

I'm guessing the RPM doesn't update CPAN database at all, thus the discrepancy. With the RPM, encryption was working correctly for me, so I know 2.22 was being used despite what CPAN said.

[anonymous]

I wonder if we need to put a warning in both configtests that the tests

will not not read accurately on some distros that do not install perl or pear modles correctly. It's impossible to be sure of anything when that happens.

[anonymous]

As a follow up, I built a brand new system (thanks VMWare) and it seems

that if I use the RPM without first installing via cpan, everything works ok. I'm wondering if on my production server I originally installed Crypt::CBC 2.17 via cpan, and then installed the RPM on top of it. Maybe the RPM isn't smart enough to update the cpan entries, but is smart enough to create it if it doesn't exist.

If that is the case, this will continue to be a problem if I manage these perl modules via RPM. I'll try making contacting with the builder and see if he has any insight into this discrepancy.