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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
