Thinking of just sitting on this for awhile? Thoughts?
Last release for PHP 5.2 & updates for 5.3
PHP Logo The users of PHP 5.2 should upgrade to 5.3 at their earliest convenience, as the active support of the 5.2 series came to an end with the release of version 5.2.14 earlier today. PHP 5.2.0 was released almost four years ago and according to the release announcement, http://www.php.net/archive/2010.php#id2010-07-22-1
the developers say that, in future, any further security fixes will only be released on a case-by-case basis. Version 5.2.14 fixes about 60 flaws, some of which present security risks such as potential memory leaks in string functions.
PHP 5.3.3 was released http://www.php.net/archive/2010.php#id2010-07-22-2 at the same time, containing approximately 100 bug fixes. Among the security-relevant bugs are buffer overflows in the native MySQL driver. This release also contains an incompatible change which concerns methods with the same name as the last element of a namespaced class name. PHP no longer treats such methods as constructors, instead regarding them as arbitrary methods:
thus, can we install php 5.3.x using yum ? Is there any repo that we can use to install the latest version of software?
2010-07-26
gaohu
发件人： Bob Hoffman 发送时间： 2010-07-26 15:04:56 收件人： centos@centos.org 抄送： 主题： [CentOS] Php 5.2.x support ends
Thinking of just sitting on this for awhile? Thoughts? Last release for PHP 5.2 & updates for 5.3 PHP Logo The users of PHP 5.2 should upgrade to 5.3 at their earliest convenience, as the active support of the 5.2 series came to an end with the release of version 5.2.14 earlier today. PHP 5.2.0 was released almost four years ago and according to the release announcement, http://www.php.net/archive/2010.php#id2010-07-22-1 the developers say that, in future, any further security fixes will only be released on a case-by-case basis. Version 5.2.14 fixes about 60 flaws, some of which present security risks such as potential memory leaks in string functions. PHP 5.3.3 was released http://www.php.net/archive/2010.php#id2010-07-22-2 at the same time, containing approximately 100 bug fixes. Among the security-relevant bugs are buffer overflows in the native MySQL driver. This release also contains an incompatible change which concerns methods with the same name as the last element of a namespaced class name. PHP no longer treats such methods as constructors, instead regarding them as arbitrary methods: _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
2010/7/26 gaohu tigerheight@gmail.com:
thus, can we install php 5.3.x using yum ? Is there any repo that we can use to install the latest version of software?
http://iuscommunity.org/ offers php 5.3.x repository to rhel and clones
-- Eero, RHCE
just this one , I found this repo yesterday. Now I'm still using my own source build php and mysql, but thie repo looks nice ? rpmfusion is good and stable ,but often is not the lastest. this one looks good, I'll try it later. Thank you !
gaohu
发件人： Eero Volotinen 发送时间： 2010-07-26 15:31:22 收件人： CentOS mailing list 抄送： 主题： Re: [CentOS] Php 5.2.x support ends
2010/7/26 gaohu tigerheight@gmail.com:
thus, can we install php 5.3.x using yum ? Is there any repo that we can use to install the latest version of software?
http://iuscommunity.org/ offers php 5.3.x repository to rhel and clones -- Eero, RHCE _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Mon, 26 Jul 2010, gaohu wrote:
To: CentOS mailing list centos@centos.org From: gaohu tigerheight@gmail.com Subject: Re: [CentOS] Php 5.2.x support ends
thus, can we install php 5.3.x using yum ? Is there any repo that we can use to install the latest version of software?
2010-07-26
gaohu
You can install PHP 5.3.2 from REMI repo, which is dependant on EPEL repo.
You will need to setup the yum-priorities plugin, and only enable REMI repo to install newer packages.
I had to set my priorities for REMI the same as Centos base repo.
To enable the REMI repo use:
yum --enablerepo=remi install php php-cli php-devel
# Name : php # Arch : i386 # Version : 5.3.2 # Release : 2.el5.remi # Size : 3.3 M # Repo : installed # Summary : The PHP HTML-embedded scripting language. (PHP: Hypertext # : Preprocessor) # URL : http://www.php.net/ # License : PHP # Description: PHP is an HTML-embedded scripting language. PHP attempts to # : make it easy for developers to write dynamically generated # : webpages. PHP also offers built-in database integration for # : several commercial and non-commercial database management # : systems, so writing a database-enabled webpage with PHP is # : fairly simple. The most common use of PHP coding is probably # : as a replacement for CGI scripts. # : # : The php package contains the module which adds support for the # : PHP language to Apache HTTP Server.
Installing REMI PHP will also update mysql server to 5.1.8
Installed Packages Name : mysql Arch : i386 Version : 5.1.48 Release : 1.el5.remi.1 Size : 2.3 M Repo : installed Summary : MySQL client programs and shared libraries. URL : http://www.mysql.com License : GPLv2 with exceptions Description: MySQL is a multi-user, multi-threaded SQL database server. MySQL is a : client/server implementation consisting of a server daemon (mysqld) : and many different client programs and libraries. The base package : contains the MySQL client programs, the client shared libraries, and : generic MySQL files.
Here's the yum repo files for EPEL and REMI:
EPEL:
[epel] name=Extra Packages for Enterprise Linux 5 - $basearch #baseurl=http://download.fedoraproject.org/pub/epel/5/$basearch mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-5&arch=$basearch failovermethod=priority enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL priority=99
[epel-testing] name=Extra Packages for Enterprise Linux 5 - Testing - $basearch #baseurl=http://download.fedoraproject.org/pub/epel/testing/5/$basearch mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=testing-epel5&arch=$bas failovermethod=priority enabled=0 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL priority=99
REMI:
[remi] name=Les RPM de remi pour Enterprise Linux 5 - $basearch baseurl=http://rpms.famillecollet.com/enterprise/5/remi/$basearch/
http://iut-info.univ-reims.fr/remirpms/enterprise/5/remi/$basearch/ enabled=0 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-remi # failovermethod=priority priority=1
[remi-test] name=Les RPM de remi en test pour Enterprise Linux 5 - $basearch baseurl=http://rpms.famillecollet.com//enterprise/5/test/$basearch/ enabled=0 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-remi priority=1
HTH
Kind Regards,
Keith
Am 26.07.2010 09:04, schrieb Bob Hoffman:
Thinking of just sitting on this for awhile? Thoughts?
That is an upstream note.
Red Hat will support PHP 5 as shipped by them until the EOL of RHEL 5.
Though there are rumors that with release of Update 6 RHEL 5 will come with an additional PHP5.3 package set - PHP 5.3 is an ABI change. Like RHEL 5 Update 5 comes with additional samba3x and postgres84.
Regards
Alexander
On 07/26/10 12:04 AM, Bob Hoffman wrote:
Thinking of just sitting on this for awhile? Thoughts?
Last release for PHP 5.2& updates for 5.3
PHP Logo The users of PHP 5.2 should upgrade to 5.3 at their earliest convenience, as the active support of the 5.2 series came to an end with the release of version 5.2.14 earlier today. PHP 5.2.0 was released almost four years ago and according to the release announcement, http://www.php.net/archive/2010.php#id2010-07-22-1
...
sounds like a great reason to get away from using PHP entirely, since they seem to be incapable of releasing upgrades that don't massively break applications. 4 years is just too short of a life cycle for a major release used in a production system.
On 7/26/2010 9:38 AM, John R Pierce wrote:
On 07/26/10 12:04 AM, Bob Hoffman wrote:
Thinking of just sitting on this for awhile? Thoughts?
Last release for PHP 5.2& updates for 5.3
PHP Logo The users of PHP 5.2 should upgrade to 5.3 at their earliest convenience, as the active support of the 5.2 series came to an end with the release of version 5.2.14 earlier today. PHP 5.2.0 was released almost four years ago and according to the release announcement, http://www.php.net/archive/2010.php#id2010-07-22-1
...
sounds like a great reason to get away from using PHP entirely, since they seem to be incapable of releasing upgrades that don't massively break applications. 4 years is just too short of a life cycle for a major release used in a production system.
Always a dilemma. The very beauty of upstream therefore CentOS is that security issues will be backported to our current installations. In a hosting environment, you don't have to worry about breaking people's php websites/apps. The downside is the long lived old php versions do not run many of the new apps those same hosted clients wish to run. But in most cases, it's those same clients that build something and expect it to run forever and get very upset when they are told they must upgrade/rewrite their scripts.
Of note. I did a 5.2 upgrade on one of our local use systems. I don't know how much more is broken, but for certain the standard CentOS install of SquirrelMail is borked. We don't use it on that system, so no big deal. I thought I'd post this just so those with mission critical machines would know that upgrading PHP does have an effect on at least this one upstream package. I can only assume if one looked deep enough, some other things may be broken as well. It really is hard to test 'everything' that a client may be using.
To me, the fact that PHP seems to have a 4 year life cycle, further strengthens the use of CentOS with its 7 year life cycle. Yes, it is an inconvenience from time to time. We don't get to count how many times it is a convenience however. You only hear when it doesn't or can't work, not how many times something continues to work due to this mindset.
John Hinton
2010/7/26 John Hinton webmaster@ew3d.com:
On 7/26/2010 9:38 AM, John R Pierce wrote:
On 07/26/10 12:04 AM, Bob Hoffman wrote:
Thinking of just sitting on this for awhile? Thoughts?
Last release for PHP 5.2& updates for 5.3
PHP Logo The users of PHP 5.2 should upgrade to 5.3 at their earliest convenience, as the active support of the 5.2 series came to an end with the release of version 5.2.14 earlier today. PHP 5.2.0 was released almost four years ago and according to the release announcement, http://www.php.net/archive/2010.php#id2010-07-22-1
...
sounds like a great reason to get away from using PHP entirely, since they seem to be incapable of releasing upgrades that don't massively break applications. 4 years is just too short of a life cycle for a major release used in a production system.
Always a dilemma. The very beauty of upstream therefore CentOS is that security issues will be backported to our current installations. In a hosting environment, you don't have to worry about breaking people's php websites/apps. The downside is the long lived old php versions do not run many of the new apps those same hosted clients wish to run. But in most cases, it's those same clients that build something and expect it to run forever and get very upset when they are told they must upgrade/rewrite their scripts.
Of note. I did a 5.2 upgrade on one of our local use systems. I don't know how much more is broken, but for certain the standard CentOS install of SquirrelMail is borked. We don't use it on that system, so no big deal. I thought I'd post this just so those with mission critical machines would know that upgrading PHP does have an effect on at least this one upstream package. I can only assume if one looked deep enough, some other things may be broken as well. It really is hard to test 'everything' that a client may be using.
To me, the fact that PHP seems to have a 4 year life cycle, further strengthens the use of CentOS with its 7 year life cycle. Yes, it is an inconvenience from time to time. We don't get to count how many times it is a convenience however. You only hear when it doesn't or can't work, not how many times something continues to work due to this mindset.
Well, mainly problem is that rhel/centos is shipping so old php version and mysql.
and "lack" of reliable source for newer versions for production.. I hope rhel 6/centos 6 fixes this problem also..
-- Eero
From: Eero Volotinen eero.volotinen@iki.fi
Well, mainly problem is that rhel/centos is shipping so old php version and mysql. and "lack" of reliable source for newer versions for production.. I hope rhel 6/centos 6 fixes this problem also..
It will temporarily fix the problem... But in n years, we will have once more the same discussion and will hope centos 7 will solve this problem... Rinse and repeat ^_^ On the opposite side, I recently tried to explain to some mplayer dev why having dev (alpha,beta,rc) and prod(stable) versions was a good idea... but they stood by their "alaways compile the latest svn version" and "it helps debug the application faster" (true, but a pain for users) stances.
JD
-
Alexander Dalloz -
Bob Hoffman -
Eero Volotinen -
gaohu -
John Doe -
John Hinton -
John R Pierce -
Keith Roberts