On Fri, Jun 02, 2006 at 05:33:27AM -0400, Walt Reed wrote: > On Thu, Jun 01, 2006 at 05:13:00PM -0400, Bowie Bailey said: > > 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. +1. Personally, I think there are probably two classes of system being represented here - standard server installs which use a small to moderate set of perl modules basically as OS components, and perl application/web servers whose main purpose is running (often custom) perl apps with much larger numbers of modules, often with specific version requirements. In the former case you can often get away with sticking to using perl RPMs and you get the audit, consistency, and homogeneity benefits that come with that. But for the second case the convenience and breadth of CPAN simply outweighs the benefits of a more rigorous package-based approach. Another useful option for those who decide to go the CPAN route is to investigate the CPAN::Mini family of modules, which allow you to setup a local CPAN mirror on your lan (analogous to a local yum repository) and have your local machines use that, ensuring consistency across your machines, and allowing you to control the rate at which you accept changes from upstream, etc. Cheers, Gavin