Hi
Thanks to all who responded. But I repeat the question: how to upgrade CentOS4 to PHP 5.2.5 correctly? 1. download form php.net + make ... etc. 2. or go search rpms/rpm in private repositories ?
On Jan 13, 2008 1:53 PM, Santa Claus santa.claus.rpm@gmail.com wrote:
Thanks to all who responded. But I repeat the question: how to upgrade CentOS4 to PHP 5.2.5 correctly?
There is no "correct" method for this, there are only "less wrong" ways to do it.
- download form php.net + make ... etc.
No. This method is not advisable at all, because it circumvents the package management of the system. This point stands for every distro with a package manager, not just centos.
- or go search rpms/rpm in private repositories
You can go this route, however if you do, you'll have to seek some of your support from them, as well as trusting them for security updates, and proper building. I would really not recommend moving to php 5.25 at all.
If you're absolutely dead set on poking the tiger with this particular pointy stick, you can get the packages from the atomic rocket turtle repository (no I am not making up that name).
Jim Perrin wrote:
On Jan 13, 2008 1:53 PM, Santa Claus santa.claus.rpm@gmail.com wrote:
Thanks to all who responded. But I repeat the question: how to upgrade CentOS4 to PHP 5.2.5 correctly?
There is no "correct" method for this, there are only "less wrong" ways to do it.
- download form php.net + make ... etc.
No. This method is not advisable at all, because it circumvents the package management of the system. This point stands for every distro with a package manager, not just centos.
I think 'make' to something like '/opt/php-5.2.5' would be "less wrong". At least that is where i keep my 'make'd apps.
Suggestions?
Anup Shukla wrote:
Jim Perrin wrote:
On Jan 13, 2008 1:53 PM, Santa Claus santa.claus.rpm@gmail.com wrote:
Thanks to all who responded. But I repeat the question: how to upgrade CentOS4 to PHP 5.2.5 correctly?
There is no "correct" method for this, there are only "less wrong" ways to do it.
- download form php.net + make ... etc.
No. This method is not advisable at all, because it circumvents the package management of the system. This point stands for every distro with a package manager, not just centos.
I think 'make' to something like '/opt/php-5.2.5' would be "less wrong". At least that is where i keep my 'make'd apps.
apache has php dependencies, so you'll be replacing that too? and, in turn, php has dependencies on dozens of other RPMs, like libraries, databases, yada yada. it spirals out.
John R Pierce wrote:
Anup Shukla wrote:
Jim Perrin wrote:
Thanks to all who responded. But I repeat the question: how to upgrade CentOS4 to PHP 5.2.5 correctly?
There is no "correct" method for this, there are only "less wrong" ways to do it.
- download form php.net + make ... etc.
No. This method is not advisable at all, because it circumvents the package management of the system. This point stands for every distro with a package manager, not just centos.
I think 'make' to something like '/opt/php-5.2.5' would be "less wrong". At least that is where i keep my 'make'd apps.
apache has php dependencies, so you'll be replacing that too? and, in turn, php has dependencies on dozens of other RPMs, like libraries, databases, yada yada. it spirals out. _______________________________________________
Yes, i have been bitten by this. But at times you are left with no option. I *needed* 5.2.x and so had to compile and install apache and php both.
In addition, since php wont compile with the available mysql, i had to put a copy (static) of the same.
And then it was the extensions and a plethora of other things.
It was more work than what i would like to put in.
But given the situation that i *must* compile something on my own, i think its better to put it in "/opt" or something similar.
Santa Claus wrote:
Hi
Thanks to all who responded. But I repeat the question: how to upgrade CentOS4 to PHP 5.2.5 correctly?
- download form php.net http://php.net + make ... etc.
- or go search rpms/rpm in private repositories
?
you can get what you want with this repo info:
[dag] name=Dag RPM Repository for *Red Hat Enterprise Linux* baseurl=http://apt.sw.be/redhat/el$releasever/en/$basearch/dag gpgcheck=0 enabled=1
Mark
Mark Weaver wrote:
Santa Claus wrote:
Hi
Thanks to all who responded. But I repeat the question: how to upgrade CentOS4 to PHP 5.2.5 correctly?
- download form php.net http://php.net + make ... etc.
- or go search rpms/rpm in private repositories
?
you can get what you want with this repo info:
[dag] name=Dag RPM Repository for *Red Hat Enterprise Linux* baseurl=http://apt.sw.be/redhat/el$releasever/en/$basearch/dag gpgcheck=0 enabled=1
dag/rpmforge does *NOT* provide php 5.2.x.
For php 5.2.x on CentOS 4 and 5 I would recommend the "Les RPM de Remi" repository at http://remi.collet.free.fr/index.php It contains only the bits necessary for php 5.2.x and it's the least intrusive repository for php 5.2.5 on CentOS 4 and 5 that I've found.
-tgc
Santa Claus wrote:
Hi
Thanks to all who responded. But I repeat the question: how to upgrade CentOS4 to PHP 5.2.5 correctly?
- download form php.net http://php.net + make ... etc.
- or go search rpms/rpm in private repositories
I've got them here - but absolutely no support whatsoever. http://www.pennywasted.info/centos/yjl.php
Only for i386 right now. It's basically a rebuild of Fedora 8 src.rpm and I track them for security patches, but not often (once a month).
Given you've had insecure apps installed, I would suggest installing the suhosin module as well. It may break your apps, but when it does, that's usually a good thing (apps it breaks are usually doing things very incorrectly).
Santa Claus wrote:
Hi
Thanks to all who responded. But I repeat the question: how to upgrade CentOS4 to PHP 5.2.5 correctly?
- download form php.net + make ... etc.
- or go search rpms/rpm in private repositories
?
I would personally recommend that you not do it at all ... if you want cutting edge and not enterprise software, then CentOS is probably NOT the distro that you want to install.
However, here IS a source of newer PHP and mysql RPMS that I know do work and I think will be maintained for a long period of time:
Thanks, Johnny Hughes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
on 1/15/2008 8:20 AM Johnny Hughes spake the following: | Santa Claus wrote: |> Hi |> |> Thanks to all who responded. |> But I repeat the question: |> how to upgrade CentOS4 to PHP 5.2.5 correctly? |> 1. download form php.net + make ... etc. |> 2. or go search rpms/rpm in private repositories |> ? | | I would personally recommend that you not do it at all ... if you want | cutting edge and not enterprise software, then CentOS is probably NOT | the distro that you want to install. | | However, here IS a source of newer PHP and mysql RPMS that I know do | work and I think will be maintained for a long period of time: | I can't understand why people choose an enterprise distro for it's longevity, and then proceed to try and break it. It is almost like buying a brand new car and then immediately replacing the engine.
- -- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't!!!!
--- Scott Silva ssilva@sgvwater.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
on 1/15/2008 8:20 AM Johnny Hughes spake the following: | Santa Claus wrote: |> Hi |> |> Thanks to all who responded. |> But I repeat the question: |> how to upgrade CentOS4 to PHP 5.2.5 correctly? |> 1. download form php.net + make ... etc. |> 2. or go search rpms/rpm in private repositories |> ? | | I would personally recommend that you not do it at all ... if you want | cutting edge and not enterprise software, then CentOS is probably NOT | the distro that you want to install. | | However, here IS a source of newer PHP and mysql RPMS that I know do | work and I think will be maintained for a long period of time: | I can't understand why people choose an enterprise distro for it's longevity, and then proceed to try and break it. It is almost like buying a brand new car and then immediately replacing the engine.
MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't!!!! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHjN/tRADw9lziUqQRAqhqAJ91kHl7OqzaxJ7VY+kCLQEDagCOkwCfRXNh
H54hkJBD4GBJL6iOD83s7ok= =Ch61 -----END PGP SIGNATURE-----
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Does Having your cake and eating come to mind?
Steven Vishoot wrote:
I can't understand why people choose an enterprise distro for it's longevity, and then proceed to try and break it. It is almost like buying a brand new car and then immediately replacing the engine.
Does Having your cake and eating come to mind?
No, because in this case your cake disappears in thin air as soon as you try to eat it. Replacing major components in CentOS really goes against the entire idea of an enterprise linux distro. Do it only if you really really have to and if you really understand every implication of it.
You make your apps work on CentOS/RHEL, you don't make CentOS/RHEL work with your apps. This is how the enterprise work. The application vendors of enterprise grade apps test and develop to the enterprise linux distros.
I am afraid the analogy police will have to come and arrest you... :)
//Morten
Scott Silva wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
on 1/15/2008 8:20 AM Johnny Hughes spake the following: | Santa Claus wrote: |> Hi |> |> Thanks to all who responded. |> But I repeat the question: |> how to upgrade CentOS4 to PHP 5.2.5 correctly? |> 1. download form php.net + make ... etc. |> 2. or go search rpms/rpm in private repositories |> ? | | I would personally recommend that you not do it at all ... if you want | cutting edge and not enterprise software, then CentOS is probably NOT | the distro that you want to install. | | However, here IS a source of newer PHP and mysql RPMS that I know do | work and I think will be maintained for a long period of time: | I can't understand why people choose an enterprise distro for it's longevity, and then proceed to try and break it. It is almost like buying a brand new car and then immediately replacing the engine.
it's a case of update-itis. In general the Linux community is partially responsible due to historical development processes we've all become accustomed to, but in most part MS is responsible for getting people to believe they need to have the latest and greatest.
Scott Silva wrote:
I can't understand why people choose an enterprise distro for it's longevity, and then proceed to try and break it. It is almost like buying a brand new car and then immediately replacing the engine.
Well, life is not that black and white, luckily ;)
Try authenticating with PHP to MySQL using certificates. That won't work with the current PHP release shipped with RHEL/CentOS. There's a bug in PHP 5.1 and it's fixed in 5.2. Since this is not a security bug, but just missing (of wrongly implemented) functionality, it's probably not going to be back ported.
Since certificates (and PKI) are a pretty hot item these days, an upgrade can be very useful.
Just an idea that upgrading is not always about having the latest and greatest.. ;)
Cheers,
Bart
Bart wrote:
Scott Silva wrote:
I can't understand why people choose an enterprise distro for it's longevity, and then proceed to try and break it. It is almost like buying a brand new car and then immediately replacing the engine.
Well, life is not that black and white, luckily ;)
Try authenticating with PHP to MySQL using certificates. That won't work with the current PHP release shipped with RHEL/CentOS. There's a bug in PHP 5.1 and it's fixed in 5.2. Since this is not a security bug, but just missing (of wrongly implemented) functionality, it's probably not going to be back ported.
Since certificates (and PKI) are a pretty hot item these days, an upgrade can be very useful.
Just an idea that upgrading is not always about having the latest and greatest.. ;)
Did you file a bug that says, hey ... your php is broken like this, here is what it will not do ?
If so, what is the upstream bug so I can track it ... if not, why not :D
Johnny Hughes wrote:
Bart wrote:
Well, life is not that black and white, luckily ;)
Try authenticating with PHP to MySQL using certificates. That won't work with the current PHP release shipped with RHEL/CentOS. There's a bug in PHP 5.1 and it's fixed in 5.2. Since this is not a security bug, but just missing (of wrongly implemented) functionality, it's probably not going to be back ported.
Since certificates (and PKI) are a pretty hot item these days, an upgrade can be very useful.
Just an idea that upgrading is not always about having the latest and greatest.. ;)
Did you file a bug that says, hey ... your php is broken like this, here is what it will not do ?
If so, what is the upstream bug so I can track it ... if not, why not :D
No, we did not ;) We opened a Service Request at RHEL, and asked them if php bug #37620 will be fixed, or if they will upgrade to php 5.2. The response we got was that RH is selling RH Application Stack v2, which does include php 5.2. And they asked us if there is an CVEs related to this bug..
Bottom line was.. either buy the application stack, or hand over the CVEs. Since this bug is not security related, there is no CVEs.
Cheers,
Bart
Bart wrote:
Johnny Hughes wrote:
Bart wrote:
Well, life is not that black and white, luckily ;)
Try authenticating with PHP to MySQL using certificates. That won't work with the current PHP release shipped with RHEL/CentOS. There's a bug in PHP 5.1 and it's fixed in 5.2. Since this is not a security bug, but just missing (of wrongly implemented) functionality, it's probably not going to be back ported.
Since certificates (and PKI) are a pretty hot item these days, an upgrade can be very useful.
Just an idea that upgrading is not always about having the latest and greatest.. ;)
Did you file a bug that says, hey ... your php is broken like this, here is what it will not do ?
If so, what is the upstream bug so I can track it ... if not, why not :D
No, we did not ;) We opened a Service Request at RHEL, and asked them if php bug #37620 will be fixed, or if they will upgrade to php 5.2. The response we got was that RH is selling RH Application Stack v2, which does include php 5.2. And they asked us if there is an CVEs related to this bug..
Bottom line was.. either buy the application stack, or hand over the CVEs. Since this bug is not security related, there is no CVEs.
Is this what you are talking about???
http://bugs.php.net/bug.php?id=37620
and if so, explain how that affects PKI authorization and I will be glad to file a bug and make lots of community noise ...
Or if you would, file a bug on bugs.centos.org that explains exactly how pki cna not be used with php and I will file an upstream bug to see if they will fix it.
Now, they will not fix every bug, but non-functional PKI is one I think that they will address.
Thanks, Johnny Hughes
Johnny Hughes wrote:
Bart wrote:
Johnny Hughes wrote:
Bart wrote:
Well, life is not that black and white, luckily ;)
Try authenticating with PHP to MySQL using certificates. That won't work with the current PHP release shipped with RHEL/CentOS. There's a bug in PHP 5.1 and it's fixed in 5.2. Since this is not a security bug, but just missing (of wrongly implemented) functionality, it's probably not going to be back ported.
Since certificates (and PKI) are a pretty hot item these days, an upgrade can be very useful.
Just an idea that upgrading is not always about having the latest and greatest.. ;)
Did you file a bug that says, hey ... your php is broken like this, here is what it will not do ?
If so, what is the upstream bug so I can track it ... if not, why not :D
No, we did not ;) We opened a Service Request at RHEL, and asked them if php bug #37620 will be fixed, or if they will upgrade to php 5.2. The response we got was that RH is selling RH Application Stack v2, which does include php 5.2. And they asked us if there is an CVEs related to this bug..
Bottom line was.. either buy the application stack, or hand over the CVEs. Since this bug is not security related, there is no CVEs.
Is this what you are talking about???
http://bugs.php.net/bug.php?id=37620
and if so, explain how that affects PKI authorization and I will be glad to file a bug and make lots of community noise ...
Or if you would, file a bug on bugs.centos.org that explains exactly how pki cna not be used with php and I will file an upstream bug to see if they will fix it.
Now, they will not fix every bug, but non-functional PKI is one I think that they will address.
Thanks! I'll get back on this tomorrow (time for sleep now!)..
Do you mind if I mail the details directly to you?
Cheers,
Bart
Bart wrote:
Johnny Hughes wrote:
Bart wrote:
Johnny Hughes wrote:
Bart wrote:
Well, life is not that black and white, luckily ;)
Try authenticating with PHP to MySQL using certificates. That won't work with the current PHP release shipped with RHEL/CentOS. There's a bug in PHP 5.1 and it's fixed in 5.2. Since this is not a security bug, but just missing (of wrongly implemented) functionality, it's probably not going to be back ported.
Since certificates (and PKI) are a pretty hot item these days, an upgrade can be very useful.
Just an idea that upgrading is not always about having the latest and greatest.. ;)
Did you file a bug that says, hey ... your php is broken like this, here is what it will not do ?
If so, what is the upstream bug so I can track it ... if not, why not :D
No, we did not ;) We opened a Service Request at RHEL, and asked them if php bug #37620 will be fixed, or if they will upgrade to php 5.2. The response we got was that RH is selling RH Application Stack v2, which does include php 5.2. And they asked us if there is an CVEs related to this bug..
Bottom line was.. either buy the application stack, or hand over the CVEs. Since this bug is not security related, there is no CVEs.
Is this what you are talking about???
http://bugs.php.net/bug.php?id=37620
and if so, explain how that affects PKI authorization and I will be glad to file a bug and make lots of community noise ...
Or if you would, file a bug on bugs.centos.org that explains exactly how pki cna not be used with php and I will file an upstream bug to see if they will fix it.
Now, they will not fix every bug, but non-functional PKI is one I think that they will address.
Thanks! I'll get back on this tomorrow (time for sleep now!)..
Do you mind if I mail the details directly to you?
Directly to me is fine, yes.
Johnny Hughes napsal(a):
Is this what you are talking about???
http://bugs.php.net/bug.php?id=37620
and if so, explain how that affects PKI authorization and I will be glad to file a bug and make lots of community noise ...
Or if you would, file a bug on bugs.centos.org that explains exactly how pki cna not be used with php and I will file an upstream bug to see if they will fix it.
Now, they will not fix every bug, but non-functional PKI is one I think that they will address.
Thanks, Johnny Hughes
Johnny, it doesn't work the way you say. I can name two bugs I consider serious: https://bugzilla.redhat.com/show_bug.cgi?id=178417 https://bugzilla.redhat.com/show_bug.cgi?id=243909
They are long-term bugs with no results. :o( Regards, David
Scott Silva wrote:
| I can't understand why people choose an enterprise distro for it's longevity, and then proceed to try and break it. It is almost like buying a brand new car and then immediately replacing the engine.
php is not a major component of RHEL/CentOS. Upgrading PHP is not going to break the system. Worst case scenario it does not work as well, in which case it is trivial to remove it and install the vendor version.
Now if he had been asking for the new version of gnome or something like that, then your analogy would be correct.
There are legitimate reasons to run CentOS 5 and update the installed php. Most users are probably better off with the CentOS provided version, but not everyone fits the description of most users.
I do what I do because it makes life easier for me. Normally life is easier for me when I do not replace the OS Vendor packages. Sometimes, however, a few things are easier when I do. php 5.2.5 is an example for me. I do not know if it is the case for the OP or not, maybe he would be better with 5.1.x - but if he needs 5.2.x there's a damn good chance installing CentOS and replacing the php will give him a far more stable system then installing Fedora 8 would.
Michael A. Peters wrote:
Scott Silva wrote:
| I can't understand why people choose an enterprise distro for it's longevity, and then proceed to try and break it. It is almost like buying a brand new car and then immediately replacing the engine.
php is not a major component of RHEL/CentOS. Upgrading PHP is not going to break the system. Worst case scenario it does not work as well, in which case it is trivial to remove it and install the vendor version.
Now if he had been asking for the new version of gnome or something like that, then your analogy would be correct.
There are legitimate reasons to run CentOS 5 and update the installed php. Most users are probably better off with the CentOS provided version, but not everyone fits the description of most users.
I do what I do because it makes life easier for me. Normally life is easier for me when I do not replace the OS Vendor packages. Sometimes, however, a few things are easier when I do. php 5.2.5 is an example for me. I do not know if it is the case for the OP or not, maybe he would be better with 5.1.x - but if he needs 5.2.x there's a damn good chance installing CentOS and replacing the php will give him a far more stable system then installing Fedora 8 would.
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 replaced packages).
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.
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 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.
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.
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 replaced packages).
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.
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.
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 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. 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.
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.
//Morten
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)
I need to make a correction - the zend abi (not api) has changed - but modules built against the old abi work in the new abi.
php 5.1.6 zend-abi = 20050922 php 5.2.5 zend-abi = 20060613
-
Anup Shukla -
Bart -
David Hrbáč -
Jim Perrin -
John R Pierce -
Johnny Hughes -
Mark Weaver -
Michael A. Peters -
Morten Torstensen -
Santa Claus -
Scott Silva -
Steven Vishoot -
Tom G. Christensen