3

I have successfully configured and compiled php on my dev server, and works great, but after talking to a sysadmin buddy, he informed that custom compiles of the latest builds are not recommended for production (or even development) systems. He noted a situation where they custom configured and compiled PHP 5.3.6, only to find that there was some issue with a low-level Postgres driver, so they had to revert back to 5.3.3.

So I am considering going back to yum to install PHP, however I have several custom configuration settings and was wondering if it's possible to pass or configure how PHP will be compiled through YUM?

My current configure line:

Configure Command =>  './configure'  '--with-libdir=lib64' '--prefix=/usr/local/_custom/app/php' '--with-config-file-path=/usr/local/_custom/app/php/etc' '--with-config-file-scan-dir=/usr/local/_custom/app/php/etc/modules' '--disable-all' '--with-apxs2=/usr/sbin/apxs' '--with-curl=/usr/sbin/curl' '--with-gd' '--with-iconv' '--with-jpeg-dir=/usr/lib' '--with-mcrypt=/usr/bin' '--with-pcre-regex' '--with-pdo-mysql=mysqlnd' '--with-png-dir=/usr/lib' '--with-zlib' '--enable-ctype' '--enable-dom' '--enable-hash' '--enable-json' '--enable-libxml' '--enable-mbstring' '--enable-mbregex' '--enable-pdo' '--enable-session' '--enable-simplexml' '--enable-xml' '--enable-xmlreader' '--enable-xmlwriter'
Mike Purcell
  • 1,688
  • 7
  • 30
  • 53
  • Is there a particular reason you're custom-compiling instead of using precompiled packages? If you're just looking for non-prehistoric versions, [Remi Collet's repo](http://rpms.famillecollet.com/) is worthwhile. Remi is the package manager for PHP in Fedora. – Charles Jun 18 '12 at 18:15
  • It's not that I want to maintain bleeding edge releases, however there are situations where various versions provide new functionality (as well as bug fixes). For example, CentOS maintains 5.3.3, however in 5.3.7 there was a feature addition for Curl which allowed for redirect support. Normally I try to wait 3 months before updating to a newer version of php, but to wait two years (5.3.3 release) seems overkill. Citation sourced via PHP change log: http://www.php.net/ChangeLog-5.php – Mike Purcell Jun 18 '12 at 20:15

4 Answers4

6

Download src.rpm for the package, it contains ORIGINAL source code and all the files required for compiling custom rpm's:

  • php.spec - spec file needed for rpmbuild
  • php-xxx.tar.gz - original source code
  • various patches (.diff, .patch)
  • documentation files to be added (if exist)

To build rpm - you will need rpm-build package which contains rpmbuild program.

It also can be done with yumdownloader (from yum-utils package):

yum install yum-utils rpm-build

yumdownloader --source php

Install src.rpm:

rpm -Uvh *.src.rpm

cd to rpmbuild SPEC dir;

RHEL5, old Fedora

cd /usr/src/redhat/SPEC/

Suse:

cd /usr/src/packages/SPEC/

RHEL6, newer Fedora:

cd ~/rpmbuild/SPEC/

php.spec file contains details about how package is built and which components will be included. It also contains data regarding dependencies and required packages to have in order to build new packages correctly. So, rpmbuild will remind you about any missing packages.

You will need to:

  1. Download updated php source code from php.net and put it into SOURCES dir
  2. Specify new version in "Version:" string in the php.spec file, also use lower value in "Release:" string and add your custom name in it, like "Release: 0.mike"
  3. Check .spec file for possible additional changes (maybe there are some security patches not needed in current version, rpmbuild will tell you about that if file is already patched). Maybe you will need to comment some "Patch xx:" string and some "%patch xx" if you will have any problems.

  4. run rpmbuild:

    rpmbuild --target x86_64 -ba php.spec

--target x86_64 - specifies platform (can be i386, x86_64, amd64, etc)

-ba - "build all", will build both final .rpm and new src.rpm packages

You can find built packages in ../RPM/ and ../SRPM/ directories.

This method ensures, that vendor patches are included, directory. file structure hierarchy is the same, component is compatible, dependencies are met and old version will be safely replaced. Also, you guarantee your future updates.

p.s. I disagree with "new version in production is bad" string. I am providing support services to dozen of companies, also have shared hosting and I always prefer to have fresh version. Only problem with php is moving from one subversion to another (like 5.1.x to 5.2.x, 5.2.x to 5.3.x) - there are some general changes and deprecated/removed functions. But newer is faster, secure and better maintained, followed.

p.s.s. I'll never compile anything manually and put files in /usr/local/ in my life, I've learned rpm as I needed it in few days, now everything is running smooth.

GioMac
  • 4,444
  • 3
  • 24
  • 41
  • Nice answer. Based on other answers and comments, it looks like this is the closest I can get to customizing the php install while still taking advantage of the backport patches. – Mike Purcell Jun 15 '12 at 16:32
  • 1
    `--target` is typically not necessary unless you're cross-compiling, but check your spec file for other requirements. For example, for building a CentOS 6 kernel, you'll typically want `--with-firmware` and `-D 'dist el6' -D 'rhel 6'`. – BMDan Jun 15 '12 at 18:41
  • --target is setting macro file to use, ex: /usr/lib/rpm/platform/x86_64-linux/macro, which contains additional flags, so, it's really good to have details specified where possible. I use amd64, by default goes to x86_64. for SPEC there may be other details too, nobody exactly knows how RH is building packages, that's the main difference between RHEL and centos, but for PHP there is nothing more to do. – GioMac Jun 16 '12 at 00:38
  • Thanks again for a great answer, I will look to using this solution in the future. – Mike Purcell Jun 19 '12 at 21:11
1

No, unfortunately you can't specify custom configure commands with yum. The software provided by yum and other similar package installers is pre-built per vendor specs.

I'd also recommend not going with the latest build of something just because its available, especially on production systems. I've encountered similar issues as your buddy where some strange bug reared its ugly head and I spent hours, days, weeks tracking it down...or just ended up reverting to the old build.

I would do a custom php build as you have done, which is what we do at my company. When a new stable version of php is out, we build it in /usr/local/php-x.x.x, test it, then update binary symlinks and shared libs in /etc/ld.so.conf.d and we're good. Developers always have requests for specific features, so its necessary for us to have the freedom and flexibility of a custom build. You could keep an eye on what version of php CentOS is recommending/distributing, and update at that time.

Banjer
  • 3,854
  • 11
  • 40
  • 47
  • I rarely go with the latest build, simply to say "hey look we are on the latest and greatest". But there are situations where new versions provide new features (as well as necessary bug fixes). – Mike Purcell Jun 18 '12 at 20:16
0

Yum is not compiler

You can try to manually compile PHP:

cd /tmp;
wget http://ua.php.net/get/php-5.2.17.tar.gz/from/ua2.php.net/mirror; # latest 5.2
tar -xzvf php-YOU_VER.tar.gz;
cd php-YOU_VER;
./configure --enable-cgi --disable-cli --with-png-dir=/usr/local --with-jpeg-dir=/usr/local --with-gd --enable-ftp --with-curl --with-zlib --enable-zip --with-iconv --enable-mbstring --with-mysql --with-freetype-dir=/usr/local --with-ttf --enable-gd-native-ttf --with-mysqli --with-libdir=lib64;
make;
make install;
dobs
  • 101
  • 3
  • Ya this is what I did to install PHP now. The only problem with compiling manually is you miss out on any backport security fixes that CentOS upstream may provide. – Mike Purcell Jun 13 '12 at 17:25
  • @MikePurcell : That is exactly why if you want to trust CentOS with providing you with security fixes, then you have to use whatever choices they made for compiling php. – chutz Jun 14 '12 at 07:13
0

like GioMac said and adding to it. The way to this is to take the source rpm of the version of php you have compiled from the yum repos and extract the src rpm and add your customization to it. Build the rpm and do a

yum localinstall <rpm>

Still that leaves the original concern of sys admin unanswered. Your customization to php may have a bug that didnt show up in your dev box. So one way to solve it would be to test it in a test environment and once satisfied push it to production.

yum is not a compiler. So installing through yum doesn't solve any problem that is present in the code. yum just make package dependencies solving easier. One benefit i see is that packages are to some extend tested before releasing it in stable branch of the repo. So if you want to compile it yourself then you loose the benefit of stable branch. if it is just configuration changes you would like to make then you can do that post installation also by editing the php.ini file.

bagavadhar
  • 538
  • 4
  • 14