| Summary: | Zend/PHP extensions don't install correct with PHP 5 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Andreas Korthaus <akorthaus> |
| Component: | [OLD] Server | Assignee: | PHP Bugs <php-bugs> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | slyoldfox |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | php-ext-base.eclass patch | ||
Some additional information:
The eAccelerator-ebuild uses the php-ext-base_addtoinifiles function from php-ext-source.eclass, which inherits this function from php-ext-base.eclass. But php-ext-base_addtoinifiles can only make changes to php4 php.ini, not to php5 php.ini.
php-ext-base_addtoinifiles uses the $PHPINIFILELIST variable, which is created by php-ext-base_buildinilist function. Here you have "php4" hardcoded, so it only works correct with PHP 4.
From php-ext-base.eclass:
PHPINIFILELIST=
for x in ${PHPSAPILIST} ; do
if [ -f /etc/php/${x}-php4/php.ini ]; then
PHPINIFILELIST="${PHPINIFILELIST} etc/php/${x}-php4/php.ini"
fi
done
I don't know how to make PHP-extension ebuilds work with both - php4 and php5. For example there is a php-sapi.eclass AND a php5-sapi.eclass, one with "php4" hardcoded, other with php5. But this doesn't work with Zend extensions, which have to work with both versions.
The same problem: http://bugs.gentoo.org/show_bug.cgi?id=75946#c7
I attached a small patch for /usr/portage/eclass/php-ext-base.eclass which uses
PHP_MAJOR_VERSION="`php-config --version | awk '{print substr($1, 1, 1)}' 2>/dev/null`"
to find out the major version of PHP. I don't know if this is the best way, but it works for me.
Created attachment 48555 [details]
php-ext-base.eclass patch
I have tried your patch and after applying it I was able to merge the xdebug-1.3.2 ebuild and it correctly added its INI entries to my /etc/php/apache2-php5/php.ini and /etc/php/cli-php5/php.ini files.
There are, however, some issues with your patch:
1.) awk is used in global scope (QA issue).
2.) I am not sure how to handle PHP_MAJOR_VERSION if a user has both
PHP 4 and PHP 5 installed.
Sebastian, At the moment, users can have php 4 or php 5 installed, but not both. The php 5 eclass sets a blocker on php 4. Best regards, Stu Sebastian, that has been my first thought before using awk, too. What I tried was: $ grep -l awk /usr/portage/eclass/* /usr/portage/eclass/ccc.eclass /usr/portage/eclass/check-kernel.eclass /usr/portage/eclass/eutils.eclass /usr/portage/eclass/games-etmod.eclass /usr/portage/eclass/games-q3mod.eclass /usr/portage/eclass/kernel-2.eclass /usr/portage/eclass/kernel-mod.eclass /usr/portage/eclass/kmod.eclass /usr/portage/eclass/mount-boot.eclass /usr/portage/eclass/nsplugins.eclass /usr/portage/eclass/php-sapi.eclass /usr/portage/eclass/php5-sapi.eclass /usr/portage/eclass/tetex.eclass /usr/portage/eclass/toolchain.eclass /usr/portage/eclass/vim.eclass /usr/portage/eclass/webapp.eclass /usr/portage/eclass/x11.eclass So this would not be the only eclass using "awk". But I do not like it too. Perhaps you find a better solution! Stuart, for me everything looks like if it should be possible to use php4 and php5 in parallel. You could not use 2 mod_php's, but mod_php + php-cgi or 2 php-cgi's will work. Why does portage prevent this? I think portage is flexible enough to make this work! Hi, We use the dev-php/php (CLI sapi) install to also install support scripts for PEAR and PECL installation. Those scripts have the same name w/ PHP 4 and PHP 5, but are different. Best regards, Stu |
After updating from php4 to php5 (php + mod_php) I have a problem with php-ext-base.eclass: If I install a Zend extension it is installed into the correct extension-dir..., but the wrong php.ini's are patched (the old ones from php4). The reason is, that "php4" is hardcoded in "/usr/portage/eclass/php-ext-base.eclass": PHPINIFILELIST= for x in ${PHPSAPILIST} ; do if [ -f /etc/php/${x}-php4/php.ini ]; then PHPINIFILELIST="${PHPINIFILELIST} etc/php/${x}-php4/php.ini" fi done I did an update from php4 to php5 this way: emerge unmerge php nano /etc/portage/package.keywords: > dev-php/mod_php ~x86 > dev-php/php ~x86 emerge php Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: # etc-update: 2) /etc/php/apache1-php4/php.ini /etc/php/apache1-php4/._cfg0000_php.ini 3) /etc/php/cli-php4/php.ini /etc/php/cli-php4/._cfg0000_php.ini but php4 was removed Expected Results: # etc-update: 2) /etc/php/apache1-php5/php.ini /etc/php/apache1-php5/._cfg0000_php.ini 3) /etc/php/cli-php5/php.ini /etc/php/cli-php5/._cfg0000_php.ini because php5 is installed I used the eAccelerator ebuild from bug 75946: http://bugs.gentoo.org/attachment.cgi?id=47087&action=view via portage overlay # cat /etc/portage/package.keywords dev-php/mod_php ~x86 dev-php/php ~x86 dev-php/eaccelerator ~x86 installed versions: # qpkg -I -v dev-php dev-php/eaccelerator-0.9.2a * dev-php/mod_php-5.0.3 * dev-php/php-5.0.3 * # qpkg -I -v apache net-www/apache-1.3.33 * the eaccelerator.so has been installed to: # locate eaccelerator.so /usr/lib/php/extensions/no-debug-non-zts-20041030/eaccelerator.so It is the extension-dir of php5: # cat /etc/php/cli-php5/php.ini | grep extension_dir extension_dir = /usr/lib/php/extensions/no-debug-non-zts-20041030 # cat /etc/php/cli-php4/php.ini | grep extension_dir extension_dir = /usr/lib/php/extensions/no-debug-non-zts-20020429