PEAR::DB is not properly detected by configtest.php

[rjl]

Marc Fournier reports (regarding configtest.php):

FAILED: DB.php installed in: but not in include path: .:/usr/local/share/smarty:/usr/local/share/pear

But:

# ls -lt /usr/local/share/pear/DB.php
-r--r--r--  1 root  wheel  38937 Apr 22 04:09 /usr/local/share/pear/DB.php

And its finding all of the other Pear modules, just not that one ... 

It appears that $db_path in his case is empty, which suggests that:

$db_info['filelist']['DB.php']['installed_as']

may not be correct in the latest PEAR Package v2 schema for PEAR::DB. The 'filelist' and/or 'installed_as' elements may have been renamed or moved to another part of the data structure, so we may need to account for this.

[rjl]

Just adding some version number specifics from Marc Fournier:

PHP       5.1.2
PEAR      1.4.6
PEAR::DB  1.7.6 (pear-DB-1.7.6,1)

[anonymous]

same problem here using Mandriva 2006.0 any quick fix for a new user just starting out with maia?

[rjl]

I believe the problem is just with configtest.php; if you know you've got a recent version of PEAR::DB installed, you can probably disregard the configtest.php "failure". You'll find out pretty quickly when you try logging into the Maia web interface in any case--if it truly can't find PEAR::DB, it simply won't work, and you'll find errors in your web server's log to that effect.

For our reference, though, can you share the version numbers for your PHP, PEAR, and PEAR::DB? It might help us narrow down the source of the problem.

[frodo@…]

php vers....PHP 5.0.4 (cli) (built: Apr 13 2006 15:07:58) Copyright (c) 1997-2004 The PHP Group Zend Engine v2.0.4-dev, Copyright (c) 1998-2004 Zend Technologies

Pear vers...Version 1.3.5 Release Date 2005-02-18 Release License PHP License Release State stable

Pear DB vers...Version 1.7.6 Release Date 2005-04-11 Release License PHP License Release State stable thanks for all your work...I really like maia!!!...just wish I had it all working you are correct about the pages still functioning properly! I'm still having trouble with AmavisD...had it working before I started installing maia...perhaps I should join the mail list and get some help there once again thank you!

[dmorton]

PEAR::DB is not distributed as a version 2 package yet. I converted it to a version 2 package using pear convert, but it still works for me.

I'm downlaoding an ISO of mandriva to see what it does. (VMWARE rocks!) If anything this looks like a possible problem with specific distros that somehow munge the install.

[dmorton]

cannot duplicate problem on FC5, suse... Mandriva won't load in VMWare.

Since the code seems to work with a version 2 package.xml, I'm at acomplete loss. Unless we can reproduce it somewhere, I think this ticket should be closed as invalid.

[rjl]

You might want to try something like Xen or QEMU instead of VMWare. Xen is particularly suited to running different Linux distos.

[dmorton]

I have a windows host at home right now; vmware is the best suited as far as I know. It runs all other forms of linux just fine; but it gives some sort of disk error with the mandriva install kernel.

It's typical of my experience with mandrake/mandriva. Every time I have used it, I experience kernel faults, seg faults, and weird problems when compiling things. It's just not a stable OS, and I would not recommend using it for a server.

[Serge]

I've the same problem with a new install. OS: FreeBSD PHP: 4.4.2

Error: FAILED: DB.php installed in: but not in include path: .:/usr/local/share/pear/

All other modules are recognized without problem.

Grtz, Serge

[dmorton]

Joe reports it broken on Suse 10.1

I'm loading a vmware server now...

[rjl]

It seems to be a mixed bag, now: we've got some reports involving PHP 5.0.4, 5.1.2, and 4.4.2, which kind of shoots down the theory that it might be a PHP5-related issue. I suppose it could still be a PHP 4.4+ issue, if something significant changed between 4.3 and 4.4.

Still, it seems like it ought to be a PEAR-related issue, since this comes back empty:

$db_info['filelist']['DB.php']['installed_as']

If the package format hasn't changed, what else could cause this to happen? Do these distros install PEAR::DB using a modified filename, perhaps (i.e. something other than 'DB.php')?

[rjl]

Another few data points submitted today from users who have no problems with configtest.php. CentOS 4.3 with PHP 5 and PEAR::DB 1.7.6 works fine. Gentoo with PHP 5.1.4 and PEAR::DB 1.7.6 also apparently works fine.

[rjl]

See #336 for some workaround suggestions.

[dmorton]

If the problem is that the distros are failing to update the pear registry, then ultimately the distros need this bug report; They are installing the software incorrectly. We can try to work around it a little, but I'd much prefer the distro's get it right.

[rjl]

It seems to be just Gentoo that doesn't update the PEAR registry. The fact that pear5 list works on distros like SuSE 10.1 suggests the registry is being updated, it's just that the PEAR registry object can't seem to see them. Perhaps there's a new "PEAR 5" registry object that we should be consulting as well?

[dmorton]

In the case of Suse 10.1, the PEAR_Config object has the wrong install directory, which means that

    	$pear = new PEAR_Config();
        $pear_reg = new PEAR_Registry($pear->get('php_dir'));

Doesn't retrieve the right info. I created symlinks in Suse 10.1:

ln -s /usr/share/php5 /usr/lib/php
ln -s /usr/share/php5/PEAR /usr/lib/php/pear

and all works ok.

So in the end, this isn't Maia's problem, and yet it is a problem.

Can we find a better way to specify the 'php_dir' in the constructor for PEAR_Registry?

[dmorton]

Oh, just realized, I didn't have quite the same error; My error on SUSE 10.1 was actually just that PEAR::DB wasn't found. It didn't get to the part of the code where it looks at the path.

[jflowers@…]

Here is the return from a FreeBSD 6.1-RELEASE print_r($dbinfo) using the pear-1.4.6 and pear-DB-1.7.6,1 ports:

[DB.php] => Array
                (
                    [role] => php
                    [baseinstalldir] => /
                    [md5sum] => ea7037643a27c7d1eb0f818efcbf35ee
                    [replacements] => Array
                        (
                            [0] => Array
                                (
                                    [from] => @package_version@
                                    [to] => version
                                    [type] => package-info
                                )

                        )

                )

[dmorton]

in [1133] I'm adding a warning about this ticket; We aren't anywhere near

a solution yet.