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.