I need to upgrade PHP because the latest WordPress requires one at least at 5.2.4. What are the tradeoffs of using the php53 packages provided by CentOS versus IUS? I've seen that installing the RHEL-derived php53 requires removing php first and it creates package conflicts because it doesn't provide a virtual php-common package. That suggests I should install the IUS package. Is there any reason to avoid IUS and stay with the CentOS package?
http://www.bytebot.net/blog/archives/2011/07/24/updating-php-in-rhelcentos-5-6-for-wordpress-3-2
On Thu, Aug 18, 2011 at 09:54:56PM -0700, Kenneth Porter wrote:
install the IUS package. Is there any reason to avoid IUS and stay with the CentOS package?
No, not really.
TUV broke php53 and it won't be fixed in any useful timeframe; IUS' packages are sane, well maintained and used by Rackspace for their own customers.
I wouldn't use the TUV php53 for any reason the way things stand.
John
On 19 August 2011 06:22, John R. Dennison jrd@gerdesas.com wrote:
On Thu, Aug 18, 2011 at 09:54:56PM -0700, Kenneth Porter wrote:
install the IUS package. Is there any reason to avoid IUS and stay with the CentOS package?
No, not really.
TUV broke php53 and it won't be fixed in any useful timeframe; IUS' packages are sane, well maintained and used by Rackspace for their own customers.
I wouldn't use the TUV php53 for any reason the way things stand.
+1 especially if you need mcrypt we have switched production servers to ius after having fought with the native offering
mike
On 08/19/2011 07:22 AM, John R. Dennison wrote:
On Thu, Aug 18, 2011 at 09:54:56PM -0700, Kenneth Porter wrote:
install the IUS package. Is there any reason to avoid IUS and stay with the CentOS package?
No, not really.
TUV broke php53 and it won't be fixed in any useful timeframe; IUS' packages are sane, well maintained and used by Rackspace for their own customers.
I wouldn't use the TUV php53 for any reason the way things stand.
In what way did TUV break php?
Regards, Dennis
On Fri, Aug 19, 2011 at 04:25:28PM +0200, Dennis Jacobfeuerborn wrote:
In what way did TUV break php?
The package supplies "php53" and not "php" - while this may arguably be correct in some situations it is not the case across the board and causes dep issues with some packaged php scripts. There is also no "mcrypt" support in the php53 packages.
There are other issues as well but these are the two big show-stoppers.
John
On 08/19/11 10:51 PM, John R. Dennison wrote:
On Fri, Aug 19, 2011 at 04:25:28PM +0200, Dennis Jacobfeuerborn wrote:
In what way did TUV break php?
The package supplies "php53" and not "php" - while this may arguably be correct in some situations it is not the case across the board and causes dep issues with some packaged php scripts.
the postgres updates managed to solve similar problems by providing a compat-postgresql-libs package which satisfies dependencies for earlier versions.
perhaps something like this could act as a glue between php and php53
At Sat, 20 Aug 2011 00:16:02 -0700 CentOS mailing list centos@centos.org wrote:
On 08/19/11 10:51 PM, John R. Dennison wrote:
On Fri, Aug 19, 2011 at 04:25:28PM +0200, Dennis Jacobfeuerborn wrote:
In what way did TUV break php?
The package supplies "php53" and not "php" - while this may arguably be correct in some situations it is not the case across the board and causes dep issues with some packaged php scripts.
the postgres updates managed to solve similar problems by providing a compat-postgresql-libs package which satisfies dependencies for earlier versions.
perhaps something like this could act as a glue between php and php53
Different issues. php53 *replaces* php. I did this on both a A CentOS 4 and two CentOS 5 machines. Mostly painless -- just needed to
'yum remove php...'
THEN
'yum install php53...'
(I did some magic with rpm -qa php* & sed to get the proper list of stuff to remove and then install.)
I did need to rebuild one package from a source RPM on one machine (and I ended up not needing it after all -- the code that need it 'evolved' in a different direction).
On Sat, 2011-08-20 at 07:43 -0400, Robert Heller wrote:
(I did some magic with rpm -qa php* & sed to get the proper list of stuff to remove and then install.)
One does not require the ''
Server 6 : rpm -qa php* php-pdo-5.1.6-27.el5_5.3 php-mbstring-5.1.6-27.el5_5.3 php-cli-5.1.6-27.el5_5.3 php-mcrypt-5.1.6-15.el5.centos.1 php-common-5.1.6-27.el5_5.3 php-mysql-5.1.6-27.el5_5.3 php-5.1.6-27.el5_5.3 phpmyadmin-2.11.11.3-2.el5.rf Server 6 : rpm -qa php* php-pdo-5.1.6-27.el5_5.3 php-mbstring-5.1.6-27.el5_5.3 php-cli-5.1.6-27.el5_5.3 php-mcrypt-5.1.6-15.el5.centos.1 php-common-5.1.6-27.el5_5.3 php-mysql-5.1.6-27.el5_5.3 php-5.1.6-27.el5_5.3 phpmyadmin-2.11.11.3-2.el5.rf Server 6 :
On Sat, Aug 20, 2011 at 01:49:12PM +0100, Always Learning wrote:
On Sat, 2011-08-20 at 07:43 -0400, Robert Heller wrote:
(I did some magic with rpm -qa php* & sed to get the proper list of stuff to remove and then install.)
One does not require the ''
Yes you do. Especially if there are any files in the directory that would match php*. Basically the shell will attempt to do glob expansion on php* (so if you have php.ini and php.conf in the directory then it'll expand to those). Only if no files match will it leave the php* as php*.
So general good practice is to _always_ quote * (and ?) characters on command lines. You can either \ the character or put the whole thing inside '
eg rpm -qa 'php*' or rpm -qa php*
But rpm -qa php* is considered bad and _may_ break and should not be used. It's just bad practice.
Watch: $ ls $
So an empty directory. We'd expect the command to work... $ rpm -qa php* php-mbstring-5.1.6-27.el5_5.3 php-common-5.1.6-27.el5_5.3 php-cli-5.1.6-27.el5_5.3 php-5.1.6-27.el5_5.3
Yup! So far so good. Now let's create some random files... $ touch php.foobar php.ini php.baz $ rpm -qa php* $
Huh, no results. Let's debug... $ set -x $ rpm -qa php* + rpm -qa php.baz php.foobar php.ini $
You can see the shell has done what I described; php* has been expanded (since it's a file glob) to the files in the directory that matched
Quoting solves the problem: $ rpm -qa php* + rpm -qa 'php*' php-mbstring-5.1.6-27.el5_5.3 php-common-5.1.6-27.el5_5.3 php-cli-5.1.6-27.el5_5.3 php-5.1.6-27.el5_5.3
(Debug mode was still on, so you can see how the shell handled it).
Conclusion: when using * (or ?) on the command line, ALWAYS quote it to avoid unexpected side effects.
On Sat, 2011-08-20 at 09:02 -0400, Stephen Harris wrote:
On Sat, Aug 20, 2011 at 01:49:12PM +0100, Always Learning wrote:
On Sat, 2011-08-20 at 07:43 -0400, Robert Heller wrote:
(I did some magic with rpm -qa php* & sed to get the proper list of stuff to remove and then install.)
One does not require the ''
Yes you do. Especially if there are any files in the directory that would match php*. Basically the shell will attempt to do glob expansion on php* (so if you have php.ini and php.conf in the directory then it'll expand to those). Only if no files match will it leave the php* as php*.
So general good practice is to _always_ quote * (and ?) characters on command lines. You can either \ the character or put the whole thing inside '
eg rpm -qa 'php*' or rpm -qa php*
But rpm -qa php* is considered bad and _may_ break and should not be used. It's just bad practice.
Watch: $ ls $
So an empty directory. We'd expect the command to work... $ rpm -qa php* php-mbstring-5.1.6-27.el5_5.3 php-common-5.1.6-27.el5_5.3 php-cli-5.1.6-27.el5_5.3 php-5.1.6-27.el5_5.3
Yup! So far so good. Now let's create some random files... $ touch php.foobar php.ini php.baz $ rpm -qa php* $
Huh, no results. Let's debug... $ set -x $ rpm -qa php*
- rpm -qa php.baz php.foobar php.ini
$
You can see the shell has done what I described; php* has been expanded (since it's a file glob) to the files in the directory that matched
Quoting solves the problem: $ rpm -qa php*
- rpm -qa 'php*'
php-mbstring-5.1.6-27.el5_5.3 php-common-5.1.6-27.el5_5.3 php-cli-5.1.6-27.el5_5.3 php-5.1.6-27.el5_5.3
(Debug mode was still on, so you can see how the shell handled it).
Conclusion: when using * (or ?) on the command line, ALWAYS quote it to avoid unexpected side effects.
Thank you. I see the strange unexpected effect:
Server 6 : mkdir /example Server 6 : ls /example Server 6 : cd /example Server 6 : .l total 12 drwxr-xr-x 2 root root 4096 Aug 20 14:06 . drwxr-xr-x 24 root root 4096 Aug 20 14:06 .. Server 6 : Server 6 : Server 6 : touch php.foobar php.ini php.baz Server 6 : .l total 12 drwxr-xr-x 2 root root 4096 Aug 20 14:07 . drwxr-xr-x 24 root root 4096 Aug 20 14:06 .. -rw-r--r-- 1 root root 0 Aug 20 14:07 php.baz -rw-r--r-- 1 root root 0 Aug 20 14:07 php.foobar -rw-r--r-- 1 root root 0 Aug 20 14:07 php.ini Server 6 : ls php.baz php.foobar php.ini Server 6 : rpm -qa php* Server 6 : Server 6 : cd / Server 6 : rpm -qa php* php-pdo-5.1.6-27.el5_5.3 php-mbstring-5.1.6-27.el5_5.3 php-cli-5.1.6-27.el5_5.3 php-mcrypt-5.1.6-15.el5.centos.1 php-common-5.1.6-27.el5_5.3 php-mysql-5.1.6-27.el5_5.3 php-5.1.6-27.el5_5.3 phpmyadmin-2.11.11.3-2.el5.rf Server 6 :
Yes. Very unexpected results !
Thanks again.
Paul Always Learning.
At Sat, 20 Aug 2011 13:49:12 +0100 CentOS mailing list centos@centos.org wrote:
On Sat, 2011-08-20 at 07:43 -0400, Robert Heller wrote:
(I did some magic with rpm -qa php* & sed to get the proper list of stuff to remove and then install.)
One does not require the ''
One does for tcsh. Bash is different.
Server 6 : rpm -qa php* php-pdo-5.1.6-27.el5_5.3 php-mbstring-5.1.6-27.el5_5.3 php-cli-5.1.6-27.el5_5.3 php-mcrypt-5.1.6-15.el5.centos.1 php-common-5.1.6-27.el5_5.3 php-mysql-5.1.6-27.el5_5.3 php-5.1.6-27.el5_5.3 phpmyadmin-2.11.11.3-2.el5.rf Server 6 : rpm -qa php* php-pdo-5.1.6-27.el5_5.3 php-mbstring-5.1.6-27.el5_5.3 php-cli-5.1.6-27.el5_5.3 php-mcrypt-5.1.6-15.el5.centos.1 php-common-5.1.6-27.el5_5.3 php-mysql-5.1.6-27.el5_5.3 php-5.1.6-27.el5_5.3 phpmyadmin-2.11.11.3-2.el5.rf Server 6 :
On 08/20/11 4:43 AM, Robert Heller wrote:
Different issues. php53*replaces* php. I did this on both a A CentOS 4 and two CentOS 5 machines. Mostly painless -- just needed to
pg x.y versions prior to 9.0 replaced the PG 8.1 that came in EL5 (9.0 and later install to new directories so they can exist side by side). further, the newer libpq isn't directly compatible with the older libpq, so this compat-libs package provides a 'shim' library to fake the older version.
$ rpm -qf /usr/lib/libpq.so.4.1 compat-postgresql-libs-4-1PGDG.rhel5 $ rpm -qf /usr/lib/libpq.so.5.1 postgresql-libs-8.3.11-1PGDG.el5
pg x.y versions prior to 9.0 replaced the PG 8.1 that came in EL5 (9.0 and later install to new directories so they can exist side by side). further, the newer libpq isn't directly compatible with the older libpq, so this compat-libs package provides a 'shim' library to fake the older version.
$ rpm -qf /usr/lib/libpq.so.4.1 compat-postgresql-libs-4-1PGDG.rhel5 $ rpm -qf /usr/lib/libpq.so.5.1 postgresql-libs-8.3.11-1PGDG.el5
That looks like the PGDG postgres repos to me and not the distribution postgres package, What is done there is pretty much out of scope for that which Redhat does for their postgres/postgres84 packaging.
On 08/20/11 10:33 AM, James Hogarth wrote:
That looks like the PGDG postgres repos to me and not the distribution postgres package, What is done there is pretty much out of scope for that which Redhat does for their postgres/postgres84 packaging.
yes, it is, but my point was, 'we' (or rather RH) could learn a trick or two from that. simply providing a dummy RPM that had dependencies on php53 and provides php would resolve these issues, unless there's an older package dependent on php that flat doesn't work on php53.
-
Always Learning -
Dennis Jacobfeuerborn -
James Hogarth -
John R Pierce -
John R. Dennison -
Kenneth Porter -
Michael Simpson -
Robert Heller -
Stephen Harris