I could use some assistance getting CPAN functional again. CPAN stopped working on Centos 4.2 x64, and I can no longer install modules. I did a install Bundle::CPAN and upgraded to 1.8.2, and perl was updated afterwards via yum update. The error seems related to GPG, does anyone know if 1.8.2 added new restrictions on signatures?
$ sudo perl -MCPAN -e shell
cpan shell -- CPAN exploration and modules installation (v1.82) ReadLine support enabled
cpan> install DBD::SQLite CPAN: Storable loaded ok Going to read /usr/share/cpan/Metadata Database was generated on Wed, 18 Jan 2006 20:10:08 GMT Running install for module DBD::SQLite Running make for M/MS/MSERGEANT/DBD-SQLite-1.11.tar.gz CPAN: Digest::SHA loaded ok CPAN: Module::Signature loaded ok WARNING: This key is not certified with a trusted signature! Primary key fingerprint: 2E66 557A B97C 19C7 91AF 8E20 328D A867 450F 89EC Signature for /usr/share/cpan/sources/authors/id/M/MS/MSERGEANT/CHECKSUMS ok CPAN: Compress::Zlib loaded ok Checksum for /usr/share/cpan/sources/authors/id/M/MS/MSERGEANT/DBD-SQLite-1.11.tar.gz ok Scanning cache /usr/share/cpan/build for sizes Deleting from cache: /usr/share/cpan/build/DBD-Oracle-1.16 (16.1>10.0 MB) Usage: Cwd::getcwd() at /usr/lib/perl5/5.8.5/File/Path.pm line 267.
cpan>
Jeff Montagna
Am Do, den 19.01.2006 schrieb Jeff Montagna um 18:34:
I could use some assistance getting CPAN functional again. CPAN stopped working on Centos 4.2 x64, and I can no longer install modules. I did a install Bundle::CPAN and upgraded to 1.8.2, and perl was updated afterwards via yum update. The error seems related to GPG, does anyone know if 1.8.2 added new restrictions on signatures?
$ sudo perl -MCPAN -e shell
cpan shell -- CPAN exploration and modules installation (v1.82) ReadLine support enabled
cpan> install DBD::SQLite
Jeff Montagna
Do yourself a favour and avoid using CPAN (had been discussed here on the list in length).
http://dag.wieers.com/packages/perl-DBD-SQLite/ http://centos.karan.org/el4/extras/stable/i386/RPMS/repodata/repoview/perl-D...
(http://centos.karan.org/el4/extras/stable/i386/RPMS/repodata/repoview/P.grou... for other versions)
Both repositories have it packaged.
Alexander
Thanks for the tip on dag, but not all the modules I need are there. All arguments for and against CPAN aside, the fix is not to use PathTools 3.15. Once I upgraded to 3.16 my problem went away. Someone had a similar issue when installing BugZilla, you can follow the troubleshooting steps here: https://bugzilla.mozilla.org/show_bug.cgi?id=321855, and his solution was to revert to 3.14. Alexander Dalloz wrote:
Am Do, den 19.01.2006 schrieb Jeff Montagna um 18:34:
I could use some assistance getting CPAN functional again. CPAN stopped working on Centos 4.2 x64, and I can no longer install modules. I did a install Bundle::CPAN and upgraded to 1.8.2, and perl was updated afterwards via yum update. The error seems related to GPG, does anyone know if 1.8.2 added new restrictions on signatures?
$ sudo perl -MCPAN -e shell
cpan shell -- CPAN exploration and modules installation (v1.82) ReadLine support enabled
cpan> install DBD::SQLite
Jeff Montagna
Do yourself a favour and avoid using CPAN (had been discussed here on the list in length).
http://dag.wieers.com/packages/perl-DBD-SQLite/ http://centos.karan.org/el4/extras/stable/i386/RPMS/repodata/repoview/perl-D...
(http://centos.karan.org/el4/extras/stable/i386/RPMS/repodata/repoview/P.grou... for other versions)
Both repositories have it packaged.
Alexander
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Do yourself a favour and avoid using CPAN (had been discussed here on the list in length).
CPAN is fine, but you should use one of the tools that convert cpan archives into rpms. I personally use cpanflute2 which comes with the RPM::Specfile(3pm) archive. Its very easy to use, and within seconds (depending on the cpan modules build time) you will have an RPM and an SRPM if you like.
On another front work in the most recent versions of rpm is being done to support runtime probes for dependencies. Sounds complicated, but basically think of it as looking out side of the package management system for dependencies such that whether you install a CPAN module from an rpm or from an rpm, RPM can detect its there and thus the dependency is satisfied.
I personally prefer everything to be in a package, but I see the merits of the latter approach. Also, as an aside, the runtime dependencies are much more powerful than that, in that they can be used to put /proc/cpuinfo and gconf dependencies on packages, which I do find to be very powerfull if used appropriately.
Cheers...james
-
Alexander Dalloz -
James Olin Oden -
Jeff Montagna