Hi,
Our public library management software (PMB) runs on Apache/PHP/MySQL. It requires some additional PHP modules to run correctly, namely:
1) php-gd 2) php-yaz 3) php-xslt
I've googled and fiddled around quite a bit, and come to the following conclusions:
1) php-gd can be installed from extra repos (rpmforge IIRC), so this one's no problem.
2) To install php-yaz, I have to install the yaz library first. To do this, I download the FC6 SRPM for yaz from www.indexdata.dk, it builds without any problem, and I install the resulting libyaz3 and libyaz3-devel. Then, I can install the according PHP module with a simple 'pecl install yaz'.
3) Apparently, there's no php-xslt module around. AFAIK, the only way to have it is to build it into PHP. So I went and downloaded the PHP SRPM from one of the CentOS mirrors. I edited php.spec and added the following configure option in php.spec:
--with-xslt-sablot
After installing a myriad of build dependencies, I launched 'rpmbuild -bb --clean php.spec', and after a while, I got my /usr/src/redhat/RPMS/i386 directory chock-full with resulting PHP packages.
I uninstalled everything I already had PHP-wise, like this:
yum remove `rpm qa | grep php`
Then I simply installed my resulting RPMS like this:
rpm -ivh php-*.rpm
I checked the PHP information page (with phpinfo()), and every module needed by my application was there.
Now I wonder: how will I manage security and/or bugfix updates for PHP and its modules in the future? When simply issuing 'yum update', any update to php will squash my rebuilt version, and PMB will become dysfunctional. My first idea would be: see if there are available updates, and in that case, download the according SRPM, rebuild and reinstall the whole thing. But that sounds a bit tedious.
Or simply put a line in /etc/yum.conf:
exclude=php php-*
???
Any suggestions?
Niki
Niki Kovacs a écrit :
Hi,
Our public library management software (PMB) runs on Apache/PHP/MySQL. It requires some additional PHP modules to run correctly, namely:
- php-gd
- php-yaz
- php-xslt
Post Scriptum: I just wonder if the required php-xslt module is not identical with the CentOS 5 php-xml module. Here's what 'yum info php-xml' returns:
Summary: A module for PHP applications which use XML Description: The php-xml package contains dynamic shared objects which add support to PHP for manipulating XML documents using the DOM tree, and performing XSL transformations on XML documents.
Can anyone confirm/infirm this?
Niki
Niki Kovacs wrote:
Niki Kovacs a écrit :
Hi,
Our public library management software (PMB) runs on Apache/PHP/MySQL. It requires some additional PHP modules to run correctly, namely:
- php-gd
- php-yaz
- php-xslt
Post Scriptum: I just wonder if the required php-xslt module is not identical with the CentOS 5 php-xml module. Here's what 'yum info php-xml' returns:
Summary: A module for PHP applications which use XML Description: The php-xml package contains dynamic shared objects which add support to PHP for manipulating XML documents using the DOM tree, and performing XSL transformations on XML documents.
Can anyone confirm/infirm this?
If you had to add a switch to the configure file (you said --with-xslt-sablot) then it probably not the same.
This is the configure line I see in php-5.1.6 for centos:
./configure --build=i686-redhat-linux-gnu --host=i686-redhat-linux-gnu --target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --cache-file=../config.cache --with-libdir=lib --with-config-file-path=/etc --with-config-file-scan-dir=/etc/php.d --disable-debug --with-pic --disable-rpath --without-pear --with-bz2 --with-curl --with-exec-dir=/usr/bin --with-freetype-dir=/usr --with-png-dir=/usr --enable-gd-native-ttf --without-gdbm --with-gettext --with-gmp --with-iconv --with-jpeg-dir=/usr --with-openssl --with-png --with-pspell --with-expat-dir=/usr --with-pcre-regex=/usr --with-zlib --with-layout=GNU --enable-exif --enable-ftp --enable-magic-quotes --enable-sockets --enable-sysvsem --enable-sysvshm --enable-sysvmsg --enable-track-vars --enable-trans-sid --enable-yp --enable-wddx --with-kerberos --enable-ucd-snmp-hack --with-unixODBC=shared,/usr --enable-memory-limit --enable-shmop --enable-calendar --enable-dbx --enable-dio --with-mime-magic=/etc/httpd/conf/magic --without-sqlite --with-libxml-dir=/usr --with-xml --enable-force-cgi-redirect --enable-pcntl --with-imap=shared --with-imap-ssl --enable-mbstring=shared --enable-mbstr-enc-trans --enable-mbregex --with-ncurses=shared --with-gd=shared --enable-bcmath=shared --enable-dba=shared --with-db4=/usr --with-xmlrpc=shared --with-ldap=shared --with-mysql=shared,/usr --with-mysqli=shared,/usr/bin/mysql_config --enable-dom=shared --with-dom-xslt=/usr --with-dom-exslt=/usr --with-pgsql=shared --with-snmp=shared,/usr --enable-soap=shared --with-xsl=shared,/usr --enable-xmlreader=shared --enable-xmlwriter=shared --enable-fastcgi --enable-pdo=shared --with-pdo-odbc=shared,unixODBC,/usr --with-pdo-mysql=shared,/usr --with-pdo-pgsql=shared,/usr --with-pdo-sqlite=shared,/usr
That has --with-dom-xslt=/usr and --with-dom-exslt=/usr ... but not --with-xslt-sablot
Thanks, Johnny Hughes
Johnny Hughes a écrit :
If you had to add a switch to the configure file (you said --with-xslt-sablot) then it probably not the same.
So, in short, the only way to update rebuilt packages (since they figure in yum.conf's exclude= line) is to track the presence of updates, then download the updated SRPM, rebuild it and then rpm -Uvh the result?
Correct me if I'm wrong.
Niki
Niki Kovacs wrote:
Johnny Hughes a écrit :
If you had to add a switch to the configure file (you said --with-xslt-sablot) then it probably not the same.
So, in short, the only way to update rebuilt packages (since they figure in yum.conf's exclude= line) is to track the presence of updates, then download the updated SRPM, rebuild it and then rpm -Uvh the result?
Correct me if I'm wrong.
That is correct.
If the libraries/files that are produced are separate when using that option, you can split them out as a separate rpm ... and maybe you can continue to use the base RPMS from centos and keep yours separately.
If it modifies the (or compiles differently) the files in existing packages, then yes you will have to track and rebuild them every time.
Niki Kovacs wrote:
Hi,
Our public library management software (PMB) runs on Apache/PHP/MySQL. It requires some additional PHP modules to run correctly, namely:
- php-gd
- php-yaz
- php-xslt
I've googled and fiddled around quite a bit, and come to the following conclusions:
- php-gd can be installed from extra repos (rpmforge IIRC), so this
one's no problem.
There is a php-gd already in centos-5 ... so no RPMForge RPM is necessary.
- To install php-yaz, I have to install the yaz library first. To do
this, I download the FC6 SRPM for yaz from www.indexdata.dk, it builds without any problem, and I install the resulting libyaz3 and libyaz3-devel. Then, I can install the according PHP module with a simple 'pecl install yaz'.
I do not recommend that ... it can get overwritten on php upgrades, instead, build a php-pecl RPM. Use the SRPMS from c5 centosplus as an example ... like php-pecl-memcache-2.1.2-1.el5.centos.src.rpm or php-pecl-Fileinfo-1.0.4-3.el5.centos.src.rpm
- Apparently, there's no php-xslt module around. AFAIK, the only way to
have it is to build it into PHP. So I went and downloaded the PHP SRPM from one of the CentOS mirrors. I edited php.spec and added the following configure option in php.spec:
--with-xslt-sablot
After installing a myriad of build dependencies, I launched 'rpmbuild -bb --clean php.spec', and after a while, I got my /usr/src/redhat/RPMS/i386 directory chock-full with resulting PHP packages.
I uninstalled everything I already had PHP-wise, like this:
yum remove `rpm qa | grep php`
Then I simply installed my resulting RPMS like this:
rpm -ivh php-*.rpm
I checked the PHP information page (with phpinfo()), and every module needed by my application was there.
Now I wonder: how will I manage security and/or bugfix updates for PHP and its modules in the future? When simply issuing 'yum update', any update to php will squash my rebuilt version, and PMB will become dysfunctional. My first idea would be: see if there are available updates, and in that case, download the according SRPM, rebuild and reinstall the whole thing. But that sounds a bit tedious.
Or simply put a line in /etc/yum.conf:
exclude=php php-*
Thanks, Johnny Hughes
-
Johnny Hughes -
Niki Kovacs