| Summary: | mod_php conflicts with php: Files in /usr/lib/php/extensions | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Alexander Skwar <askwar> |
| Component: | Current packages | Assignee: | PHP Bugs <php-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | glawk01, php-bugs |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Alexander Skwar
2004-11-15 23:10:32 UTC
solution A (a master PHP package) doesn't work, as depending on some configure options, the modules can very easily be incompatible between the various parts of PHP (I can think of at least 6 seperate routes that this can happen from what I know of the PHP source).
back in the days of php4 we didn't compile readline/libedit into mod_php/php-cgi, but it ended up causing more hassles than it was worth in a few ways, and we integrated it back in as of PHP5.
The best route performance-wise with PHP is not to use the shared USE flag at all, and instead to specify exactly what extensions you want for each PHP via /etc/portage/package.use.
For extensions, I'm thinking the best route would be to put extensions into
"/usr/lib/php/extensions/${PHPSAPI}-php${PV/.*}/..." but this brings up the problem that third-party modules need to be made to put themselves in multiple locations after this.
This is basically the same problem as in #71095. The different PHP ebuilds should never install the same files to the same locations (though I never saw that error message that Alexander reports). Re the modules: can you put third-party modules in a /usr/lib/php/extensions/shared dir and load via a full path? And maybe it would be better to add the config to the .ini files, but commented out, so they have to be edited by the admin before the new module is activated. For instance a PHP accelerator doesn't need to be active in the CLI .ini. As much as I hate the idea, it might be time for us to start looking at having a single dev-php/php package, where you switch the SAPIs on and off via USE flags. For the cost of a (one-off) manual upgrade for users, we should be able to ensure that problems like this simply can't happen. And PHP will install quicker too, because users won't need to recompile PHP multiple times. The downside is loss of flexibility. All the SAPIs would end up being installed with the same options. I guess we need to find out whether that really matters or not. Best regards, Stu But please DO NOT drop support for installing multiple SAPIs at the same time! I need to be able to have both mod_php and the PHP cli installed. Others might need cli and CGI. If you can keep the ability for each PHP to use its own php.ini file then I don't see why somebody couldn't just comment out any unwanted modules. Assuming that all the built-in modules are compiled dynamically like they appear to be with the PHP5 eclass. Even if you can't do that, there is a hack in PHP CLI that looks for "php-cli.ini" before "php.ini". In my applications I only need the CLI version to be configured differently because of session directory ownership issues, and a couple other minor tweaks. I might not even need those any more, I haven't tested recently. Judging by the /usr/bin/php bugs I reported, it looks like most people don't configure their PHP's differently, probably using the stock .ini's and presumably the same USE flags. Hi, This is now fixed by the packages in the Gentoo PHP Overlay. I went down the single dev-lang/php route, and am very happy with the new approach. These packages will be available in Portage in the next few weeks, but the overlay is available for general use now. [1] http://svn.gnqs.org/projects/gentoo-php-overlay/ Best regards, Stu |
