[CentOS] Apache 2.2X

[Daniel Senie]

At 07:09 PM 11/2/2006, Tim Uckun wrote:

>>After removing all the stuff that depends on apache (mod_python, mod_ssl,
>>http_suexec, webalizer, subversion, etc.), the Apache supplied RPMs seem to
>>install fine.  Of course you wouldn't be using all the same patches and
>>configs from the CentOS rpm version, and there's no guarantee it will work
>>well with the provided libraries (it probably will provided they have all
>>their requires in the spec file correct).  If you don't need any
>>functionality out of Apache other than what you are putting in yourself
>>(rails, mongrel, mod_proxy_balance), this might work.
>
>I didn't want to start down that path of uninstalling everything and
>then reinstalling them again. I was kind of hoping there would be a
>repository I could add to repos.d and then yum upgrade httpd.
>
>I am afraid I don't have the time or the expertise to try and roll 
>my own RPMs.

Indeed this is one of the problems with RHEL distributions... they 
get stale on some of the more major packages and provide no good way 
to fix that without creating a support issue for yourselves. I had a 
chat with someone from RedHat at LinuxWorld Boston about this. 
Sounded like it was something they were hearing a lot, but hadn't 
figured out how to address.

In my case, I'd like to be running sendmail 8.13.x so as to be more 
up-to-date on milter compatability, but didn't want to be dealing 
with having to build RPMs and play the dependency issue game from there.

While it's true the next major release will incorporate the newer 
sendmail, the selling point of longer-term support is then nullified 
some. It's nice to stay on a relatively stable release and NOT have 
major upheavals in the entire platform so often, but it would be 
powerful to couple that stability with the ability to easily update 
key componentry in just one or two areas. That way, you could have 
something very stable for a platform base, plus the one newer 
component needed for a server's core function (web-related in the 
case of the poster here, email-related in my case).

Hopefully in the future there will be a way to deal with this.