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.