Re: PHP 5.0.5 and PEAR 1.4.2...together?

I have found one more problem that may or may not be serious when installing PEAR in this manner. As I said in my previous post, I was able to get PEAR and all the new versions of the PEAR modules included in PHP's source installed, but now whenever I do "pear list <package>", the file locations are listed as "/tmp/php-buildroot/usr/lib/php/xxxxxx" instead of "/usr/lib/php/xxxxxx". I tested this on a new package (DB) by using the following command-line: pear install --nodeps -R /tmp/junk/DB-1.7.6.tgz to try to use PEAR itself to install a module to another directory. This leads to the same problem (i.e. files listed as /tmp/junk/usr/lib/php/xxxxx). My question now is whether I am misunderstanding pear install's -R option or if PEAR is somehow broken. I would assume that the -R is there specifically for situations such as mine where you want to compile PHP/PECL/PEAR to live in a certain directory, but you have to temporarily install the files somewhere else (e.g. for RPM packaging). I believe the older versions of PEAR worked in this manner (i.e. 1.3.x in the PHP source never seemed to have this problem), so I'm not sure if it is a bug or a change in the way pear operates. Help would be greatly appreciated since this also affects my building of secondary RPM packages using PEAR as well. Any help would be greatly appreciated. On 10/31/05, Andrew Teixeira <ateixeira@gmail.com> wrote: > I have finally figured out how to get this to install correctly. The > first part was that I needed to change line 7 of install-pear.php to > set the include_path to $pear_dir, not empty string as it is in the > CVS version: > > ini_set('include_path', $pear_dir); > > It was actually a relative accident that I fixed the second part and > got it to work. I was trying to play with the install-pear.php code a > little and cut out a block of code dealing with removing layers from > the config so that I could paste it somewhere else. The lines were > lines 55-60 as follows: > > // make sure we use only default values > $config_layers = $config->getLayers(); > foreach ($config_layers as $layer) { > if ($layer == 'default') continue; > $config->removeLayer($layer); > } > > I cut these lines out in the attempt to paste them further down in the > code thinking that somehow the 'system' layer (which I felt was giving > me errors before) was being re-created and mucking up the works. My > mistake (which turned out to be a good thing) was that I lost track of > what I was doing and never pasted the code back in and then ran the > install again (and it worked!). It took me a minute to figure out > what I had changed in install-pear.php, but once I did, removing those > 5 lines from a new copy of install-pear.php seemed to solve the > problem. I'm not sure why this is the case, but I figured I would let > you know. I now get the files installed in my build root as well as > registry, filemap, etc. information. > > Thanks for all your help and I hope this is somewhat helpful to others. :) > > On 10/22/05, Andrew Teixeira <ateixeira@gmail.com> wrote: > > On 10/20/05, Greg Beaver <cellog@php.net> wrote: > > > Andrew Teixeira wrote: > > > > [PEAR] PEAR: pear.php.net/PEAR: conflicting files found: > > > > OS/Guess.php (pear.php.net/Object id #11) > > > > PEAR/ChannelFile/Parser.php (pear.php.net/Object id #27) > > > > PEAR/Command/Auth-init.php (pear.php.net/Object id #17) > > > > PEAR/Command/Auth.php (pear.php.net/Object id #60) > > > > [---End Snippet---] > > > > > > > > I didn't copy all the files that it said conflicted into the snippet > > > > since it went on for a good distance. > > > > > > > > The conflicting files errors seem to be for every file in every PEAR > > > > package that PHP is attempting to install. Not sure what I'm doing > > > > wrong. Please let me know your thoughts. Thanks. > > > > > > Aha - this is both a rare bug and an EXTREMELY unhelpful way of > > > reporting it to you :). > > > > > > The Object id #11 crap is a PEAR_Error object. > > > > > > see newly opened (and fixed) שËA > > > ¡|‡«‡Qä¸pVhttp://pear.php.net/bugs/5736 > > > > > > You can at the very least find the real source of your trouble by adding > > > these lines to PEAR/Registry.php at line 1840: > > > > > > if (PEAR::isError($pkgs[$name])) { > > > return $pkgs[$name]; > > > } > > > > > > > > > This will transform the checkFileMap() method into: > > > > > > ... > > > if (!in_array($attrs['role'], > > > PEAR_Installer_Role::getBaseinstallRoles())) { > > > $attrs['baseinstalldir'] = is_array($package) ? > > > $package[1] : $package; > > > } > > > if (isset($attrs['baseinstalldir'])) { > > > $name = $attrs['baseinstalldir'] . > > > DIRECTORY_SEPARATOR . $name; > > > } > > > } > > > $pkgs[$name] = $this->checkFileMap($name, $package, > > > $api, $attrs); > > > if (PEAR::isError($pkgs[$name])) { > > > return $pkgs[$name]; > > > } > > > } > > > return array_filter($pkgs, $notempty); > > > } > > > if (empty($this->filemap_cache)) { > > > ... > > > > > > Greg > > > > > > > Ok, so I did that and it did clean up the errors significantly. Now I > > can figure out what the problem is. The problem seems to manifest > > itselft in Registry.php in the _readFileMap function. The function > > errors out because $this->filemap is set to "/.filemap". I traced > > this back to what I believe is a problem when the PEAR_Registry > > constructor is called with a NULL first parameter ($pear_install_dir). > > I have put some stubs in the constructor to print out the > > $pear_install_dir value. Since install-pear.php is called twice from > > the Makefile, I get the registry initialization stubs twice. Each > > time it prints out the following values for the $pear_install_dir: > > > > - /usr/lib/php > > - /usr/lib/php > > - <NULL> > > - /tmp/php-buildroot/usr/lib/php > > > > So, for some reason I believe the installer is using the 3rd registry > > instance (with the NULL $pear_install_dir) when trying to install my > > PEAR packages, causing filemap to be /.filemap. I then tried to trace > > back where PEAR_Registry was instantiated and found that the main > > source of the problem seemed to stem from the setInstallRoot function > > in Config.php. It seems that the if (($old != $root)...) statement > > evaluates to TRUE, and then cycles through the _registry array. I > > have printed stubs here and it seems that the 'system' registry has > > php_dir set to NULL, while 'default' is set to the correct value > > (/tmp/php-buildroot/usr/lib/php). > > > > My question now is, what do I do to fix it. Is this as simple as > > telling the installer to somehow use 'default' instead of 'system', or > > is this unfortunately more complicated. Thanks for your help. > > >