Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm working on getting a Red Hat 6 LAMP server going and while the PHP that comes with it has many extensions we use, it doesn't have all of them.

To solve this, I was thinking about either

  1. compiling the PHP extensions which come in the ext folder of the downloadable source code of PHP 5.3.3 from php.net
  2. same as #1, but using the extensions from the latest PHP version (currently 5.3.8).
  3. Do #1 but manually decide which updates to backport from the latest version of the PHP extensions into the older version and then compile the backported result

A drawback to #1 is that security and bug fixes come out which we wouldn't be able to take advantage of.

A drawback to #3 is that it might be a lot of work

Does anyone know what the drawbacks to #2 are? I don't want to go down that route if it might result in some unexpected negative outcomes.

Also, are there any other drawbacks to the other options or a better way to go altogether? I want to use the PHP 5.3.3 which comes with the Linux distro because I don't want us to get to a place again where we are forced to upgrade to a new version of PHP to stay on top of security updates like from PHP 5.2.x to 5.3.x and there be backwards incompatible changes (this is the situation we're in now with PHP 5.2.x no longer being supported).

share|improve this question
1  
You may consider using the EPEL repository - its packages are compatible with the core RHEL/CentOS packages, and are usually well maintained. It should provide the majority of the missing extensions, and will be easier to keep up to date than compiling them yourself. –  cyberx86 Nov 17 '11 at 2:18
    
It appears that at least with respect to PHP extensions, EPEL would be like doing #1 but without having to compile (so if I ended up going with #1, that'd be a nice time saver). I downloaded the source of php-extras from download.fedora.redhat.com/pub/epel/6/SRPMS/repoview/… and did a recursive comparison between that and the 5.3.3. source downloaded from PHP.net and there were no differences. So that would have the same drawback of not taking advantage of security and bug fixes. –  user101203 Nov 18 '11 at 16:17
    
I believe it is advisable to have modules from the same version of PHP as you are using (since they are closely coupled to the php internals and they depend on the API which can change) - pear/pecl might be able to provide some more recent modules that are still compatible (or you could try another repository (e.g. Remi's Repo) - but the dependencies on some repositories can be a problem) –  cyberx86 Nov 18 '11 at 17:13
    
I checked out Remi's Repo and it has a couple of the extensions we need, but it doesn't have a few so in the best case it'd be a partial solution. Like you mentioned, I'm concerned about incompatibilities due to API differences, but then on the other hand if we go with the same version and it doesn't have fixes backported into it, then that leaves us potentially with known bugs and/or security issues. –  user101203 Nov 21 '11 at 18:11
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.