The PEAR directory seems to have changed to /usr/lib/php/php, but the PHP config does not have this as an include path, it still has /usr/lib/php. I am guessing that the extra /php is a mistake which needs to be removed. When using 'pear install <package>', it will be installed to /usr/lib/php/php and thus unavailable to webapps that are using .:/usr/lib/php as the include path (the default). Reproducible: Always Steps to Reproduce: 1. Install php 2. Check /etc/pear.conf Expected Results: Perhaps the extra '/php' needs removing from /etc/pear.conf, otherwise the default include paths need changing in /etc/php/<version>/php.ini. This appears to be the same on three machines I run and is "correct" on one that hasn't yet been updated to the latest php ebuild.
*** Bug 88958 has been marked as a duplicate of this bug. ***
Been that way about a month, and it is a slight annoyance. If anyone cares, I'd vote for moving them back into /usr/lib/php, or if you really want a subdir, then /usr/lib/php/pear ("/usr/lib/php/php" just seems embarassingly redundant :P). I suspect the whole subdir thing was just an accident, though.
Mike, moving to /usr/lib/php/pear or /usr/share/php or whatever won
Mike, moving to /usr/lib/php/pear or /usr/share/php or whatever won´t solve anything b/c you´d need to modify php.ini anyway. :-) Can´t we have include_path=.:/usr/lib/php:/usr/lib/php/php/ which would work for both the PEAR modules installed before and those upgraded now and prevent nitpicking like in Bug 86761? At least until this gets sorted out and Bug 76991 is fixed? Sebastian, what do you think?
I'm aware that php.ini would need to be updated. That's why I said I'd rather they move back into /usr/lib/php. I was just saying that *if* a subdirectory was specifically desired for PEAR components to keep them separate from other include files (as opposed to a simple accident as I theorize), then a subdir called "/usr/lib/php/pear" rather than "/usr/lib/php/php" (including the necessary change to the php.ini files) would be more appropriate. If using /usr/lib/php/php is intentional and permanent, then I'm fine with it. I think it was probably an accident, though, since the php.ini's would have been modified, as well. By the way, I'm amused that you refer to rockoo's desire (in bug #86761) for PEAR to actually work when installed as "nitpicking." ;)
CC-ing Sebastian as he proposed the PEAR split. Sebastian, is this directory change intentional?
The PEAR installation directory will change to /usr/share/php with PEAR-PEAR-1.3.5-r1, which is currently package.masked. This is also the first version of PEAR-PEAR that will bring the split of PEAR from PHP. AFAIK the /usr/lib/php/php path was not changed intentionally and is most likely a bug of some kind.
So very likely, this confusion will go away when PEAR-PEAR-1.3.5-r1 (and the corresponding php ebuilds) get unmasked and stabled. Satisfies me. :P
Personally, I think this was an extremely poorly implemented change. Many webapps depend on PEAR working. This inexcusably broke PEAR. It needs to have been done right or not at all. A very minimal amount of testing would have told you it was broken. Anything that is done, expecially directory changes need to be reflected in an updated php.ini (which they aren't) if I use the command line installer for pear, the paths need to be identical. I find it particularly silly to use portage to manage packages that php folks provide tools for already. Having PEAR-PEAR in the portage tree is a waste of space and not useful whatsoever. PEAR package updates can break software and need testing before deployment on servers. I could go on, but just hope I am getting across that I am extremely disappointed in the poor handling of this major change. I hope major changes aren't just made willy nilly in the future and some more thought goes into them. A fix for this is necessary soon, or send it back to ~arch and patch something that installs properly.
*** Bug 86685 has been marked as a duplicate of this bug. ***
+1 on comment #8
stable masked mod_php does not work / stable masked horde (#86761) - for 1,5 month happens nothing - plz a solution
*** Bug 86761 has been marked as a duplicate of this bug. ***
I just made a clean installation of PHP 4.3.11 on my ~x86 Gentoo system: - PEAR is installed to /usr/lib/php/php instead of /usr/lib/php. - /etc/pear.conf has php_dir = /usr/lib/php/php instead of /usr/lib/php - /etc/php/cli-php4/php.ini has include_path = ".:/usr/lib/php" I have no idea why the PHP 4.3.11 ebuild (or the php-sapi.eclass) install PEAR to /usr/lib/php/php. Installing dev-php/PEAR-* packages, however, works on my system, including the PEAR-PEAR-1.3.5 ebuild. If nobody beats me to it (Stuart?) I will try to debug why PEAR is installed to /usr/lib/php/php instead of /usr/lib/php but my time is currently limited.
I've just updated php ebuild to 4.3.11, fresh on 5/9/2005, and it suggested overwriting the /etc/apache2/conf/php.ini with a version that still has include_path = ".:/usr/lib/php in it, so I can confirm it's still broken. Jan
Sebastian, Do a diff between the last changes Robin made and current. You'll see the issue. Wendall
You mean http://www.gentoo.org/cgi-bin/viewcvs.cgi/eclass/php-sapi.eclass?r1=1.55&r2=1.56, right?
Adding --with-pear=/usr/lib/php to the php-sapi.eclass solved the problem that was introduced by Robin's multilib fix.
Yes, that was the file. :) Fix looks great, thanks Sebastian.
