Bugzilla Bug 88763

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.