Jim Perrin wrote:
On 6/1/06, Kurt Hansen <khansen@xxxxxxxxxxxxxx> 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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
