Re: PHP build --with-pear fails: conflict over /tmp/pear/cache

On Tue, 11 Mar 2008, Ofer Inbar wrote:

To: php-install@lists.php.net From: Ofer Inbar <cos@aaaaa.org> Subject: Re: [PHP-INSTALL] PHP build --with-pear fails: conflict over

    /tmp/pear/cache

Keith Roberts <keith@karsites.net> wrote:

What about trying --with-pear=/another/directory or --without-pear? Once PEAR is installed, it is able to upgrade itself, so you don't need to touch it after that. It only needs installing once.

I may be wrong about this, but doesn't --with-pear=/other/dir cause it to use that other directory forever? That is, wouldn't that replace /tmp/pear permanently for that build, so that it never uses /tmp/pear?

I used to compile PHP without any --with/out-pear ./configure options. This installed PEAR under the --prefix=/usr/local/php-5.x.x directory path. So everytime I upgraded PHP, I got a fresh installation of PEAR in a different location. I now have PEAR installed under /usr/local/PEAR. Subsequent PHP upgrades are done --without-pear, as there is no need for me to touch the working PEAR installation. It appears to me that each installation of PEAR is a seperate entity. You need to check what config files are being used by each installation of PEAR. They are quite possibly different. So another PEAR installation in a different location should use it's own set of config files. I cannot see any problems with using a different --with-pear=/new/path for testing purposes. HTH Keith Roberts

That would be undesirable for two reasons: 1. I don't want to use a nonstandard directory, it makes things confusing 2. I would have to change the name every time I did a new build, because reusing the same name I used last time would conflict with the previous build which would be installed and in use by then. If I'm wrong, then this would solve the problem. But I won't know if I'm wrong or right until after I install the resulting RPM. Building with --without-pear might be one workaround. However, I need a build procedure that is repeatable and noninteractive and does result in PHP *with* pear. The postinstall script has a bunch of pear commands to complete our configuration, so pear must be installed at some point in the RPM script. I haven't yet tried doing it as a separate step because I don't think it would solve the problem. Wouldn't it run the same pear build, and thus still try to use the same directory? What is the mechanism by which pear's initial install gets the temporary build directory location to use during build *only*? I thought it got passed from a variable in PHP's Makefile, which would explain why this worked for me in the past. -- Cos