Description: ------------ Failed install PEAR 1.4.5 with INSTALL_ROOT ( for RPM building). Without INSTALL_ROOT all fine. Test script: --------------- # make install-pear INSTALL_ROOT=/var/tmp/php-root/ Installing PEAR environment: /var/tmp/php-root//usr/share/pear/ [PEAR] Archive_Tar: PEAR_Registry: could not open filemap [PEAR] Console_Getopt: PEAR_Registry: could not open filemap warning: pear/PEAR requires package "pear/Archive_Tar" (recommended version 1.3.1) warning: pear/PEAR requires package "pear/Console_Getopt" (recommended version 1.2) pear/PEAR can optionally use package "pear/XML_RPC" (version >= 1.4.0) [PEAR] PEAR: PEAR_Registry: could not open filemap

This is still a problem with 5.1.1. And quite an annoying problem at that.

Agreed. It's totally preventing me from installing PHP 5.1.x under DarwinPorts. I'm at a loss for how to try to track down the problem. Editing the PEAR distribution .phar file causes checksum mismatch errors. How then am I intended to attempt to debug and suggest a fix for the problem?

pls, could you give us a cvsweb link to the fix? i checked out the cvs, grepped the logs for the id of this bug and found nothing thanks, Miklos Vajna

Despite this bug being close, it's still painfully broken in the context of installation from PHP5's sources. Using the following command, I get the two following results: make install-pear PHP_PEAR_PHP_BIN=/usr/bin/php PHP_PEAR_INSTALL_DIR=/usr/share/php PHP_PEAR_SYSCONF_DIR=/etc/pear PHP_PEAR_SIG_BIN=/usr/bin/gpg INSTALL_ROOT=/home/adconrad/build/php5/5.1.2/php5-5.1.2/debian/php-pear When installing as root, I end up with all the dotfiles (.channels, .registry, etc) in /usr/share/php, which is obviously very wrong. When installing as me (adconrad), I get all the dotfiles in debian/php-pear/ (note the lack of trailing /usr/share/php on there) In both cases, all the classes and such get installed correctly to debian/php-pear/usr/share/php/(...), but the dotfiles always end up on creatively wrong places. The third case, not mentioned above, is that when running as "fake root" (which is how package builds on Debian and Ubuntu tend to be done), it attempts to write to /usr/share/php, then obviously fails, since I'm not actually root. So, is something testing my UID, and trying to write to /usr/share if it can?

5.1.2 still fails here: Installing PEAR environment: /var/tmp/fst/pkg/usr/share/pear/ Warning: mkdir(): Permission denied in phar://install-pear-nozlib.phar/System.php on line 260 Warning: touch(): Unable to create file /usr/share/pear/.lock because No such file or directory in phar://install-pear-nozlib.phar/PEAR/Registry.php on line 748 Fatal error: Call to undefined method PEAR_Error::getValidationObject() in phar://install-pear-nozlib.phar/PEAR/PackageFile/v1.php on line 1203 make[1]: *** [install-pear-installer] Error 255 make: *** [install-pear] Error 2 make: *** Waiting for unfinished jobs....

I want to second adconrad's comment above: PEAR installation is painfully broken in the context of installation from PHP5's sources. I just went through several days of trying to force PEAR to install into an INSTALL_ROOT as part of creating an RPM of PHP 5.1.2 with PEAR enabled, and despite some very extreme efforts (including editing of the files in the INSTALL_ROOT to insert or remove the buildroot text, using perl's in-place editing capabilities) I was unable to get it to build cleanly, with no external dependencies or effects. The problem starts with the install-pear-installer target in the PHP makefile. This target tries to create files in the actual destination directory, regardless of the INSTALL_ROOT that's used. Beyond that, I found it impossible to build PHP with PEAR enabled if there was another version of the PHP/PEAR RPM (that I was building) already installed on the system. No matter what I did (including the aforementioned munging of INSTALL_ROOT files to disguise the real paths), the package I was making would notice the package that was already installed. As a side note for anyone who happens across this bug, the following Perl script gives a simple way to edit out the buildroot value from the registry files (and any others that use the s:len:value format); you can use similar formats to insert the buildroot value if necessary, or do other editing: perl -pi -e 's#s:([0-9]+):(.)(%{buildroot})+#"s:".($1-length($3)).":$2"#eg ;'

The same problem exists since PHP 4.4.2.