Morten Torstensen wrote:
Michael A. Peters wrote:
PHP is a module that adds functionality to Apache. The only parts of the
PHP is the programming language that drives a large chunk of web
applications out there. It is not just an apache module.
Granted. It's most common use is as an apache module, it can be used for
several other things.
Back to the point though, PHP is not a major component of
RHEL/CentOS. It the last part of a LAMP that gets installed, LAM does
not need php, php needs LAM (well, you could use Windows, IIS, Oracle
... so I guess technically not ... but anyway ...)
The point is that replacing PHP and NOT replacing all the other pieces
of glue (apache php modules, mysql php modules ...) breaks support and
introduces many unknowns into the system. Many websites would not work
if you ran it on just LAM, as the code is written in PHP and PHP needs
to interact with the other components. In my book PHP is a major part
of a web server.
PHP is a major part of a web server, yes - but it is an easily
replaceable component of CentOS without sacrificing the stability of
CentOS. The php source RPM builds php, php-common, php-cli, and almost
all of the php modules that are available to CentOS from the CentOS
repositories. You rebuild a newer version, and you get a new set that
bolts in in place of the old set.
PHP is a major component of LAMP and replacing it just because there
is a new version of PHP out with some new features and maybe some
bugfixes you don't need is NOT a good enough reason to go through all
that hassle.
I agree. One should only upgrade when a new feature really is a necessity.
YMMV. The upstream provider will backport fixes that are important
enough to backport. With an enterprise distro of Linux, you make the
apps work with what is in the base distro, NOT the other way around.
That is not always the best solution.
The current problem I am solving by using php 5.2.5 can only be done in
stock CentOS 5 by using perl. PHP does not have the functionality and
the pecl extension that does requires php 5.2.x. Maybe that pecl
extension could be ported to work in 5.1.x but it hasn't been and I
don't feel qualified to do it, nor am I willing to pay a programmer to
do it when there is a simple solution - use php 5.2.x.
You can of course do whatever you want with the computers you control,
but I really disagree that PHP is a minor component and that building
your own is easy and with no consequences to talk about.
I never said there are no consequences.
The biggest consequence - RHEL/CentOS will not support it.
However - reverting to CentOS php is as easy as a yum remove followed by
a yum install and restarting the web server.
Also note that on the repo page where I make my build available, I tell
users they are probably better off with the stock php - because they
probably are. There are situations where the stock php does not do what
you need it to do, and in those cases, the drawbacks of losing upstream
support may be outweighed by the benefit of having your stable CentOS
LAMP do what you need it to do.
If the support cycle of Fedora wasn't so darned short, perhaps Fedora
would be better for people who need a newer PHP - but Fedora's life
cycle is so short that by the time it is robust it is near EOL. The
fallout of that decision by the Fedora team is that people who need a
long lasting distribution with just a few components like PHP updated
are going to use CentOS with those few components updated. That may not
be what you consider to be "Enterprise Linux" but one of the major
strong points of FOSS is that you don't need to wait for a vendor to
patch something or provide function you need.
PHP is a relatively low risk component to update if the update is
packaged correctly. It's not no risk, but it is a low risk update.
MySQL on the other hand is not - since there are several apps that link
against it. LDAP is not because there are several apps that link against
it. Apache is not because there are several apps that link against it.
Etc. - but php from 5.1.6 to 5.2.5 is a fairly straight forward
replacement. There are not a lot of changes that require change of
existing code to properly run, and the vast majority of binary modules
just work as the zend api has not changed.
Most of the 3rd party php web applications out there have been tested in
5.2.x for some time. Not all have, but those that don't work probably
have problems in 5.1.6 as well (these would primarily be web apps that
still want php 4)
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
