Jim Perrin wrote: > On 6/1/06, Kurt Hansen <khansen at charityweb.net> wrote: > >> >> 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 > >> Is this the kind of rhetoric that is acceptable on this list? There is >> no value to your comment except to insult. > > > Actually, I was questioning the validity of that statement since RHEL > and centos are built from identical sources. Theoretically you should > have the same problem with CentOS that you do with RHEL. If something > is different, I'm sure the other admins would be interested in hearing > about it as well, since we are trying to be as compatible with RHEL as > possible. Forgive me for trying to work a little humor (at your > expense) into the day. Forgiven, of course. Let me explain further -- to use RHEL, I'd have to pay thousands per year for support. However, for the components that are most critical for my application, perl and mod_perl, I have found that the rpms from Red Hat have been defective or non-optimal. This wasn't just a one-time thing, but happened several times from RH7.X on up through FC2. This proved to me that Red Hat was unable to support the components of their system that were most critical to me. In each installation for the past couple of years, I've built an installed my own perl and mod_perl. I was also concerned that Red Hat would balk at supporting other parts of my systems if I had deviated from the supplied software. So, it didn't seem I would be getting any value for my thousands. I first went with Fedora Core, but realized over time that FC is the old rawhide. So, I've switched to CentOS on more recent systems. I roll my own perl, mod_perl, Apache, and install perl modules thru CPAN and have been doing so for the past 4 years since RH7.X. It's worked well so have stuck with it. I think Les Mikesell and Paul Heinlein later in this thread do a good job of explaining the challenges and solutions of mod_perl on RH-based systems. > As others have pointed out mod_perl has been kindly supplied via a 3rd > party repository, and I do agree that in very rare instances cpan is > useful. However, for rpmbased distributions, as much software as > humanly possible should be installed via rpm. This allows for easier > administration, software auditing, replication and portability of > packages, and in the event of failure.... blame, since the packages > tell you who built them and when. > > As others in this thread pointed out, CPAN is a moving target and > poses a level of risk as such. Packages installed via rpm (while maybe > not perfect) do not suffer from this affliction, are portable, > predictable, and can be identically duplicated across as many machines > as needed, even months down the road. The entire original meaning of > my post was to be careful, and only use cpan as a last resort on rpm > based systems. That point stands. I understand your point. Note Paul Heinlein's "laziness" comment later in this thread, and my inertia one in my original comment. I'd have to create my own SRPM's to use rpm for my own rolled solutions, correct? That would make maintainance of my system easier, correct? These are honest questions, but I just haven't had the time to learn how to build SRPMs given that all is working well for me now. Take care, Kurt