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)