PHP 5.2.12 and 5.3.0

These source RPMs are provided as is, no warranty, no guarantee. They are based on the Fedora php packaging. The php 5.2.12 (NOT YET) RPMs also have the suhosin core hardening patch for better security. Suhosin is not yet available for php 5.3.x.

It is recommended that you also install the php-suhosin dynamic module, but read the APC note.

The php-pear RPM is based on the Fedora 9 rpm but has been updated to current pear version.

I no longer will be providing any pear packages except for the base pear package, use the command line pear installer to manage your pear packages or install the noarch pear RPMs from Fedora 10. Note that in their infinite wisdom, Fedora 11 is using a version of RPM that has completely broken the ability to install any Fedora 11 RPMs in Fedora < 11 or RHEL/CentOS.

Some PECL modules are also provided. You will need to rebuild any PECL modules you use when upgrading from stock RHEL/CentOS php 5.1.x to the php versions offered here.

I highly highly highly recommend building php packages in mock. I have seen some build errors (usually happens during %check) when building PHP outside of mock and a different version of PHP is already installed on the system. You will need to configure mock to use the EPEL repository for dependencies. Make sure you set up a private repo for mock to use for building the packages that depend upon on php, or mock may pull in older php for building additional packages.

php 5.2.x vs 5.3.x

Currently, I only recommend 5.3.x for testing servers, especially since some critical PECL modules do not yet have stable versions that build for it.

Installation help on RHEL 5 based distributions if you need it is available for a fee: mpeters@mac.com.

Binary RPMs

Binary RPMs are available for a small fee. Back in the CentOS 5.1 days I use to make binary RPMs for php (and many other packages) available for free via a yum repository, but the bandwidth quickly got too expensive.

For a small donation of $7.00, you will be given access to a directory where you can download mock built binary RPMs made from the above source RPMs for a period of six months.

They are distributed as a tarball (4 tarballs actually - 5.2.x for i386, x86_64 and 5.3.x for i386 and x86_64) and have instructions on how to install the RPMs via yum.

I apologize I can't just give them away, but I just can't afford to right now.

Shopping cart coming soon.

Custom Binary Packages

If you need a binary PECL module and have paid, let me know. If providing it is only a simple matter of rebuilding a Fedora src.rpm there's a good chance I'll do it for free. If however providing it requires I heavily modify or write a spec file from scratch, I'll give you a quote.

Do not ask for memcache. Memcache is really only appropriate for server farms for building a distributed cache. Unfortunately I just do not have the resources to test such a package to make it properly works, and so I really have no business packaging it.

Do not ask for DOM PDF. I will provide it once I am convinced the new maintainers have fixed the atrocious security leak.

Custom packages for php 5.3.x will only be made available if a stable version properly works for php 5.3.x, I won't do porting work on binary modules, that's for the code maintainers to do.

APC Notes

APC as packaged here defaults to apc.cache_by_default=0 (turned off). The reason for this, when it is turned on, it interferes with some PEAR packages (for example, MDB2).

Turning it on should result in a speed bump, but test it on a development machine first.

It is possible a newer version will fix the issue, but the newer versions are not yet labeled stable, so I have not packaged them.

There are also some issues with the php-suhosin module. I've seen blank pages result, particularly login and logoff pages. It may have to do with APC doing something cache wise with session regeneration that suhosin does not like. If your site hits a database frequently, the performance boost from APC may outweigh the security benefits of suhosin, if you run into an issue you will have to make a judgment call.

I suggest wrapping APC function calls rather than using them directly. For example:

function wrap_fetch($key) {
   $key = 'webapp_' . $key;
   if (function_exists('apc_fetch')) {
      $value = apc_fetch($key);
      return $value;
      } else {
      return false;
      }
   }
   
function wrap_store($key,$value,$life=3600) {
   $key = 'webapp_' . $key;
   if (function_exists('apc_store')) {
      $rs = apc_store($key,$value,$life);
      return $rs;
      } else {
      return false;
      }
   }
   
function wrap_AOstore($key,$value,$life=3600) {
   $key = 'webapp_' . $key;
   if (function_exists('apc_store')) {
      $rs = apc_store($key,new ArrayObject($value),$life);
      return $rs;
      } else {
      return false;
      }
   }

By doing so, if you find you need to disable APC, doing so will not break your code. Using wrapper functions also makes it a little easier to avoid key clashes between different applications you are running, as you can prefix the key in the wrapper.

I recommend against using APC for File Upload Progress. While it is a very useful feature, it breaks if you need to disable APC. Use the uploadprogress PECL module instead.