[CentOS] PERL module woes

[Walt Reed]

On Thu, Jun 01, 2006 at 05:13:00PM -0400, Bowie Bailey said:
> Jim Perrin wrote:
> > > In fact, the quality of the perl-related rpms from Red Hat is
> > > the main reason I'm not using RHEL and using CentOS
> > 
> > Your logic is confusing to me. It does not resemble what I would
> > consider to be rational thought.
> 
> I think I understand what he was trying to say.  When I built my last
> system, I decided to go with rpms for everything.  It worked great
> until I got to the Perl modules and then it fell apart.
> 
> Every time I have tried to install Perl modules from rpms, it quickly
> evolves into a massive game of "find the missing dependency".  Either
> the module I want can't be found anywhere, or when I do find it, it
> depends on a module that can't be found.
> 
> I finally gave up and decided to use CPAN for Perl modules.  It is
> simple, and work amazingly well.  It does cause some annoyance when you
> get other rpms that have dependencies on Perl modules, but that is a
> problem that I have only seen once or twice.
> 
> There is a program that will create rpms from CPAN.  I considered it
> and then rejected it as being WAY too much trouble for the number of
> modules that I typically deal with.

As another software engineer / sysadmin that supports a large mod_perl
based site (about 50 servers now) I have to echo this. The latest
greatest RHEL/CentOS 4.3 perl and associated modules is WAY too old. 

I deal with well over a hundred additional perl modules beyond what is
supported in the base OS, and have been hammered by bugs in old modules
/ perl. If you are heavy users of perl, it is simply not possible to
avoid CPAN, and not possible to use the versions of modules supplied in
the base OS. I use stock packages for everything possible except apache
/ perl which all lives in /usr/local - easily replicated from system to
system. I frankly don't have time to build RPM's of every CPAN module I
use.  It would take me an extra year of labor and I just don't have that
kind of time / money to waste on purist ideals - I live in the real
world.

I have had ZERO issues over the past several years pointing
/usr/bin/perl to /usr/local/bin/perl as the local perl is a superset of
stock perl. Local scripts work fine.

The problem is basically mirrored with PHP with many advanced
applications requiring versions newer than the OS is bundled with.