Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Peter J. Holzer
July 27, 2008, 12:57 pm
rate this thread
Interesting. I'm not sure if I've even known about CPAN for 12 years,
but it's probably not much less. And for quite some time I also was in
the habit of always issuing an "install Bundle::CPAN" whenever I was
told that CPAN was out of date. And it never broke. Even when it did
obviously stupid things (like installing a new version of perl because
of a dependency on a core module) the result was always usable.
Of course I've had my occassional run-ins with modules which had
incomplete dependencies, or which required special tricks to install
(most recent example: DBD::Oracle with oracle instantclient 10.2) but
those are almost always modules outside of Bundle::CPAN. And even if
something in Bundle::CPAN failed to install (e.g., some gzip
module because gzip-devel wasn't installed) that didn't break anything
which used to work before - I just didn't get that additional feature.
I did give up on installing Bundle::CPAN, but that's for different
reasons: Firstly, a lot more modules are available for my Linux
distributions than there used to be, so I need CPAN a lot less.
Secondly, I have more servers to maintain, so building RPM and Debian
packages for those modules which are missing becomes more worthwhile.
Re: CPAN Lies!
On Linux I generally use the distribution-provided perl, unless it is
too old (RHEL 3 I think comes with perl 5.8.0, which has some issues
with unicode, and some machines still use an OS version which came with
5.6.x or even 5.005_03. On these machines I have usually built perl
myself and scripts running there tend to use /usr/local/bin/perl instead
On HP-UX, trying to use the vendor-supplied perl is hopeless, at least
if you want it to talk to an Oracle database. And the perl bundled with
Oracle Application Server is best not mentioned.