OK, so I did an upgrade to PHP 5.3 on one of my servers. I noticed the uninstall of php also removed SquirrelMail and it won't install under PHP 5.3. Has anybody worked this out with a good RPM or repo solution?
Why not just install SquirrelMail the old fashioned way?
cd /var/www wget "http://downloads.sourceforge.net/project/squirrelmail/stable/1.4.21/squirrel..." tar xvzf squirrelmail-1.4.21.tar.gz
Done.
On Tue, May 24, 2011 at 1:00 PM, John Hinton webmaster@ew3d.com wrote:
OK, so I did an upgrade to PHP 5.3 on one of my servers. I noticed the uninstall of php also removed SquirrelMail and it won't install under PHP 5.3. Has anybody worked this out with a good RPM or repo solution?
-- John Hinton 877-777-1407 ext 502 http://www.ew3d.com Comprehensive Online Solutions
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Tue, May 24, 2011 at 01:00:01PM -0400, John Hinton wrote:
OK, so I did an upgrade to PHP 5.3 on one of my servers. I noticed the uninstall of php also removed SquirrelMail and it won't install under PHP 5.3. Has anybody worked this out with a good RPM or repo solution?
Dump the CentOS php53 package and use the 5.3 provided by the IUS repository. See http://wiki.centos.org/AdditionalResources/Repositories for more information and links to IUS.
CentOS' 5.3 doesn't Provide: php and has some other issues the last time I looked.
John
Am 24.05.2011 23:41, schrieb John R. Dennison:
On Tue, May 24, 2011 at 01:00:01PM -0400, John Hinton wrote:
OK, so I did an upgrade to PHP 5.3 on one of my servers. I noticed the uninstall of php also removed SquirrelMail and it won't install under PHP 5.3. Has anybody worked this out with a good RPM or repo solution?
Dump the CentOS php53 package and use the 5.3 provided by the IUS repository. See http://wiki.centos.org/AdditionalResources/Repositories for more information and links to IUS.
CentOS' 5.3 doesn't Provide: php and has some other issues the last time I looked.
Could you elaborate what "other issues" it has?
Thx Rainer
On Wed, May 25, 2011 at 01:11:57PM +0200, Rainer Traut wrote:
Could you elaborate what "other issues" it has?
Doesn't Provide: php / php-common Lack of native mcrypt support I think there were problems with mbstring early on that may have been resolved.
Perhaps others that I am not thinking of at the moment.
The big issue is that it provides php53/php53-common and not php/php-common: this will prevent packages such as, for example, squirrelmail from installing and will have similar impact on packages from outside repos.
John
Am 25.05.2011 14:09, schrieb John R. Dennison:
On Wed, May 25, 2011 at 01:11:57PM +0200, Rainer Traut wrote:
Could you elaborate what "other issues" it has?
Doesn't Provide: php / php-common Lack of native mcrypt support I think there were problems with mbstring early on that may have been resolved.
Perhaps others that I am not thinking of at the moment.
The big issue is that it provides php53/php53-common and not php/php-common: this will prevent packages such as, for example, squirrelmail from installing and will have similar impact on packages from outside repos.
Yeah ok. Let's hope that at least for the missing mcrypt support epel steps in.
Thx Rainer
Rainer Traut wrote:
Am 25.05.2011 14:09, schrieb John R. Dennison:
On Wed, May 25, 2011 at 01:11:57PM +0200, Rainer Traut wrote:
Could you elaborate what "other issues" it has?
Doesn't Provide: php / php-common Lack of native mcrypt support
<snip>
Yeah ok. Let's hope that at least for the missing mcrypt support epel steps in.
Good grief! Back in '06 and '07, where I worked, I had to build php because it didn't have mcrypt support by default. They *still* don't, at this late date?
<shakes head>
mark
On Wed, May 25, 2011 at 10:28:00AM -0400, m.roth@5-cent.us wrote:
Good grief! Back in '06 and '07, where I worked, I had to build php because it didn't have mcrypt support by default. They *still* don't, at this late date?
I'm sure that there was a valid reason for this changelog entry from php53-5.3.3-1.el5_6.1.src.rpm but as the referenced bugzilla tickets are restricted I can't say what that reason might be. Intellectual rights issue with one of the included crypt schemes, perhaps?
* Fri Mar 26 2010 Joe Orton jorton@redhat.com - 5.3.2-2 - remove mcrypt support (#459804, #577257)
John
On Tue, May 24, 2011 at 5:41 PM, John R. Dennison jrd@gerdesas.com wrote:
Dump the CentOS php53 package and use the 5.3 provided by the IUS repository. See http://wiki.centos.org/AdditionalResources/Repositories for more information and links to IUS.
CentOS' 5.3 doesn't Provide: php and has some other issues the last time I looked.
Why should a PHP 5.3 package provide PHP? To many libs are different, and it would allow for the installation of something like php-ldap from base to a php53 which provided the php dependency. That is not how RPM's are supposed to work. PHP 5.1 is significantly different enough to warrant a different package. Would you package postgres84 to satisfy postgres? No, because it would be wrong. A more correct solution would be to change the dependencies for the cross-php packages to allow for a php or php53 to satisfy.
On Wed, May 25, 2011 at 09:43:48AM -0400, Steven Crothers wrote:
Why should a PHP 5.3 package provide PHP? To many libs are different, and it would allow for the installation of something like php-ldap from base to a php53 which provided the php dependency. That is not how RPM's are supposed to work. PHP 5.1 is significantly different enough to warrant a different package. Would you package postgres84 to satisfy postgres? No, because it would be wrong. A more correct solution would be to change the dependencies for the cross-php packages to allow for a php or php53 to satisfy.
Many packages work just fine with 5.3; a simple -compat package could Provide: php and permit such to install and work without issue.
Note that I am not arguing that there are some significant differences between the legacy 5.1 and the more modern 5.3 only that for the example I cited in a later reply should work with the 5.3 from upstream if the needed deps were matched. And to be honest, for all I know this specific issue may have already been addressed by upstream.
John
-- "I am on a drug, its called 'Charlie Sheen'. It's not available cuz if you try it once you will die. Your face will melt off and children will weep over your exploded body."
-- Charlie Sheen
On 5/24/2011 5:41 PM, John R. Dennison wrote:
On Tue, May 24, 2011 at 01:00:01PM -0400, John Hinton wrote:
OK, so I did an upgrade to PHP 5.3 on one of my servers. I noticed the uninstall of php also removed SquirrelMail and it won't install under PHP 5.3. Has anybody worked this out with a good RPM or repo solution?
Dump the CentOS php53 package and use the 5.3 provided by the IUS repository. See http://wiki.centos.org/AdditionalResources/Repositories for more information and links to IUS.
CentOS' 5.3 doesn't Provide: php and has some other issues the last time I looked.
Thanks John. The IUS repository looks really good (or reliable). It seems that they have also used the same type of naming convention used by Redhat for php53 with the addition of i or whatever. This is pretty nice for adding and removing packages. Unfortunately, I'm thinking that this will cause the same dependency problem as things like php-common won't be found.
Yes, I know I 'can' just go do an install of something like SquirrelMail, something we immediately would need, but that would potentially just be the beginning of issues on a shared hosting system. It sounds like I should just sit back and wait for 6 if I want to stay on upstream (and select repos) for package updates. That has been my hard headed decision for many years and in those many years, has proven to save a lot of future grief and eliminated in some cases some additional downtime during compiles.
Looks like if my need for PHP53 is absolute, I'll just move that client to the one 'custom' system and they'll just have to understand that there might be a bit more downtime, then move them onto a 6 box once deployed.
And yes, PHP has been the one thing that has repeatedly been the dawg with using Redhat. 6 was way late out from upstream and then the promised option in 5 appears to be at least a bit of a smoking gun.
-
John Hinton -
John R. Dennison -
m.roth＠5-cent.us -
Rainer Traut -
Steven Crothers