Re: CPAN Lies!

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
Quoted text here. Click to load it

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!

[A complimentary Cc of this posting was NOT [per weedlist] sent to
Peter J. Holzer
Quoted text here. Click to load it

In my experience, vendor-supplied perls NEVER work.  Of course, if you
complied Perl on local machine, you should have much fewer problems...

Hope this helps,

Re: CPAN Lies!

Quoted text here. Click to load it

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
of /usr/bin/perl).

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.


Site Timeline