[CentOS] Re: PHP 5.2.5 when ?

Thu Jan 17 13:05:06 UTC 2008
Michael A. Peters <mpeters at mac.com>

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)