Description: ------------ After building PHP with PEAR and installing into a DESTDIR, pear does not properly execute within the DESTDIR tree, even if appropriate arguments point to the install (i.e., non-default) location. As near as I can tell, this is because include_dir is reset at the top of pearcmd.php _before_ CLI arguments are processed: if ('/usr/lib/php' != '@'.'include_path'.'@') { ini_set('include_path', '/usr/lib/php'); $raw = false; } else { // this is a raw, uninstalled pear, either a cvs checkout, or php distro $raw = true; } ... some other code ... require_once 'PEAR.php'; require_once 'PEAR/Frontend.php'; require_once 'PEAR/Config.php'; require_once 'PEAR/Command.php'; require_once 'Console/Getopt.php'; ... more code ... $options = Console_Getopt::getopt2($argv, "c:C:d:D:Gh?sSqu:vV"); Test script: --------------- PHP_PEAR_PHP_BIN=/tmp/apache_mod_php.roots/apache_mod_php~dst/usr/bin/php \ PHP_PEAR_INSTALL_DIR=/tmp/apache_mod_php.roots/apache_mod_php~dst/usr/lib/php \ /tmp/apache_mod_php.roots/apache_mod_php~dst/usr/bin/pear \ -C /tmp/apache_mod_php.roots/apache_mod_php~dst/private/etc/pear.conf config-set \ cache_dir /tmp/pear/cache system As a simpler alternative: # "make install" into a DESTDIR such as "/tmp/Build", not final location such as /usr/lib/php etc. cd $DESTDIR/usr/bin ./php -C -q -d include_path=../lib/php ../lib/php/pearcmd.php Expected result: ---------------- I expected the configuration file to be updated. This DOES function properly if there is an older version of PHP / PEAR installed since the PEAR.php in /usr/lib/php (not the DESTDIR) is available. However, this can lead to version mismatches or, as in my case, bootstrapping problems. Actual result: -------------- Warning: require_once(PEAR.php): failed to open stream: No such file or directory in Config.php on line 21 PHP Warning: require_once(PEAR.php): failed to open stream: No such file or directory in /private/tmp/apache_mod_php.roots/apache_mod_php~dst/usr/lib/php/ PEAR/Config.php on line 21 PHP Fatal error: require_once(): Failed opening required 'PEAR.php' (include_path='/usr/lib/php') in /private/tmp/apache_mod_php.roots/apache_mod_php~dst/usr/lib/php/ PEAR/Config.php on line 21

Added patch fix-include_path.

I've attached a patch which disabled the call to ini_set() and adds a helpful log message.

I'm afraid that patch does not really solve the problem; The include path setting is there for a reason. I will have a look into if there is another way around it or if we get passed this somehow. I do realise by killing of the include path setting it allows you to pass in your own include path on run time or it uses the one from the php.ini - Need to investigate the installation time. Also, I am afraid we can not add any sort of logging like that which goes out for every single command a person runs. The reason being is that we have various switches which both dictate log levels and also the fact that certain commands have the ability to suppers any output (including error) but it wouldn't be able to for this one.

The logging was more for validating that the include_path is respected during development than to be left in for deployment. (With everything that happens during a full build, it was the only way I could see what the tool was using.) And killing the include_path _prevents_ me (not allows me) to pass it on the command line since the required code can't be loaded in a bootstrap situation. Perhaps a check for INSTALL_ROOT or DESTDIR would treat the install as raw or at least skip the ini_set?

Yeah, that may indeed be the way to go - I am going to investigate this a bit more and see if we have any knock on effects. I am going to do the logging of the include_path but in a different way, it may require you to add a higher verbosity level on the logging (such as -vvvv) to see that but at least it will be in there in a more standardized way :-)

Created PR for this https://github.com/pear/pear-core/pull/32

This bug has been fixed in SVN. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.

This bug has been fixed in SVN. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.