Johnny Hughes wrote:
If you knew exactly what you were doing and how to make your own php
... and you had a very good reason (a bug that is not be fixed, etc.),
then that might be the case.
If this were RHEL though, you just lost any php support you could get
upstream (and anything else that they MIGHT be able to relate to your
IF you are willing to do that, I guess it would be fine.
But for MOST users, this is not the case. And BTW, any of the LAMP
components I would consider a MAJOR part of the OS.
Apache and MySQL probably are major components. Lots of CentOS packages
depend upon them.
PHP is a module that adds functionality to Apache. The only parts of the
distribution that depend upon PHP are some of the web applications, such
as squirelmail, the php-pear stuff, and a few php modules that are not
built as part of main php package.
Most php extensions will work without a rebuild. Some may require a
rebuild, but that's what rpmbuild --rebuild is for (or mock, which is
cleaner way of doing rpmbuild --rebuild)
Since you redid php, you are now possibly going to need to recompile
many other things including the php-* extensions from DAG's repo and
the CentOS repos, php-mysql, etc.
I do not use DAG's repo. php-mysql etc. are all built during the build
of php. The src.rpm for php builds the vast majority of modules. A few
modules, like php-pecl-Fileinfo are not part of the main php package -
and while I did personally rebuild the CentOS src.rpm for that module, I
tested the one in CentOS and it worked without a rebuild.
Any of the php modules that have "5.1.6" in the version (from CentOS and
CentOS Extras) are modules that are distributed with php and are rebuilt
by the single 5.2.5 src.rpm.
I do not know the impact as I have not actually done the analysis.
Since /usr/lib/httpd/modules/libphp5.so MIGHT be the same name for
both (though might have different content), you may not need to
recompile any apache modules or other items.
No - you do not need to recompile any other apache modules. Apache
itself does not require php, and none of the other apache modules
require it either.
The only packages you may have to recompile are packages that have a
BuildRequires: php-devel in them.
And going from 5.1.6 to 5.2.x generally does not, as they share the same
zend api version. I don't know of a case where a module external to php
requires a rebuild, though I suppose it is possible they exist.
But, I still think php is a major item and would probably rebuild my
whole mysql / php / apache if i was considering a php upgrade.
No. PHP depends upon Apache and MySQL. Neither of those packages depend
upon PHP. PHP is not installed in the build system when those packages
are compiled, there is no way that upgrading php will break either of them.
That being said - I absolutely agree that unless you *know* you need PHP
5.2.x then you should stick to the version in your distribution.
Web hosts have lost my business because they upgraded the version of PHP
they were running without telling me at least six months in advance -
causing breakage of code. Many web hosts are still on PHP 4 for that
reason. Good web hosts will set up a new server with newer versions of
PHP and ask you if you want your domain switched to it - but don't force
you to move.
It is possible there are some web applications that work with 5.1.6 that
do not work in 5.2.5 though I have not experienced any, and looking at
their changelog, it looks like there are very few differences that might
require patching of clean code. Hell, I'm occasionally paid to port
stuff from php 3 to php 5 - and often, had they used proper code in php3
- the changes I make wouldn't be necessary.
There may be new bugs, that is always a risk when upgrading, and why it
is best to stick with CentOS version unless you *know* you need newer.
My laptop uses the CentOS version, for example, even though I'm
confident in my php 5.2.5 packages - as nothing I'm developing on my
laptop requires 5.2.x
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 ...)
Very few packages that are not built from the same src.rpm as php itself
depend upon it, and they are generally not very specific version dependent.