Summary: | app-admin/eselect-php-0.6.4 doesn't support portage-multilib on multilib-nosymlink | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Nathan Phillip Brink (binki) (RETIRED) <binki> |
Component: | [OLD] Server | Assignee: | PHP Bugs <php-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 306835 | ||
Attachments: | eselect-php-0.6.4-multilib.patch |
Description
Nathan Phillip Brink (binki) (RETIRED)
2011-07-13 12:01:35 UTC
I actually tried to support multilib without the /usr/lib symlink. However, earlier on, I got an issue that was the exact opposite. The eselect module symlinked the 64-bit version, while apache wanted the 32-bit version. I have no idea what is the correct way of determining which version apache want. (In reply to comment #1) > I have no > idea what is the correct way of determining which version apache want. The best way is to just setup all libdirs and let apache choose which version it wants ;-). I've started writing a patch which makes eselect-php do this, hopefully I'll have time tonight to finish it and attach something. Created attachment 280691 [details, diff]
eselect-php-0.6.4-multilib.patch
This fixes php's apache2 support on my multilib machine. It also works OK for cli and cgi. I don't know what fpm is. This patch also makes all of the symlinks relative instead of absolute. That reduces the amount of times the libdir has to occur in the symlink's path. So at least a working apache2+php setup can be gotten on a portage-multilib machine now :-).
The remaining problem is how eselect-php shirks around portage-multilib's abi-wrapper. For non-multislotted apps and if there is a reason to have a multilib binary, such as for appname-config binaries/scripts, /usr/bin/appname-config is set up as a symlink to /usr/bin/abi-wrapper. /usr/bin/abi-wrapper will looks for /usr/bin/appname-config-${ABI}, defaulting to the machine's native ABI. This allows the 32-bit version of appname-config to be invoked by, say, a 32-bit compilation's ./configure script for another package which uses appname. php installs even binaries into slotted and ABI-protected directories, which I think is a valid practice.
So, what I'm saying is that there's currently no way to make
$ ABI=x86 php-config
translate into running /usr/lib32/php5.3/bin/php-config and
$ ABI=amd64 php-config
translate into /usr/lib64/php5.3/bin/php-config. And just for sake of completeness, since a 32-bit version of the php binary itself is installed, it might make sense to support `ABI=x86 php'.
So, any thoughts on that? In the meantime, my current patch does fix stuff and would be helpful for portage-multilibers ;-). Maybe a proper solution to this problem will require extending eselect's /usr/share/eselect/libs/multilib.bash script to recognize the values which the ABI variable can hold instead of just having the hardcoded string of "lib lib32 lib64".
Thanks for the patch. It looks fairly straightforward. I'll look into creating a new release soon. It would be interesting to support wrapping the PHP binaries to support multilib, but I fear it may make PHP maintenance even more complicated without really supporting a larger user base. FPM is the 'new' PHP SAPI that all the cool kids use, together with servers like nginx. How's the new version coming along? I was just looking at closing bug #356467 but found we need a stable >eselect-php-0.6.2 for this. How about aiming for a stable eselect-php-0.6.5 next month? Oh my. My brain believed I had already created this release. I'll have it done tomorrow. Committed. |