Re: Pear install in 4.3.3rc4-dev

On Thursday, August 14, 2003 17:18, Derick Rethans wrote: > Hello, > recent changes in PEAR changed the default package install directory > from /usr/local/lib/php to /usr/local/lib/php/lib. This changes breaks > every existing PEAR install around because: > - The old installed packages are in a different directory > - The default (that's holy for shared hosters) include path is > /usr/local/lib/php and thus people would need to add lib/ in front of > every include/require to a pear package. > Anyway, bad move and something that should definitely NOT be done in an > upgrade from 4.3.2 to 4.3.3. Attached patch addresses the issues and > makes it work as it should again. See the point of the "stupid-lib-mess". The installer puts the files in different directories depending on the "role" of the file (defined at the package.xml file). Currently "tests", "doc", "data" get installed under the same dir of the .php files, even the native php dir "extensions". So: <root> - PEAR.php - OS/Guess.php - XML/Parser.php - docs/* - tests/* - data/* - extensions/* Normally you'll set <root> under your include_path setting, adding a lot of unneeded stuff. The new layout fixes that problem: <root> - lib/PEAR.php - lib/OS/Guess.php - lib/XML/Parser.php - docs/* - tests/* - data/* - extensions/* It's clear we need a separate dir for php libs (the php_dir setting), ok? I called this dir "lib". Then, if you compile --with-prefix=/usr, you'll end with in a (perhaps) not so clear "/usr/lib/php/lib". Ok, let's change the "lib" dir to let's say "pear". A user that compiles --with-pear=/usr/local/pear will need to add to the include_path the dir "/usr/local/pear/pear", even more silly. Now we defaults <root> to the php constant PHP_SYSCONFDIR (which defaults to /usr/local/lib/php). Perhaps we could abandon it and use our own space out of the php scope, let's say: <root=/usr/local/lib/pear> - php/PEAR.php - php/OS/Guess.php - docs/ ... You'll need to add to the include_path /usr/local/lib/pear/php, this way. -- Tomas V.V.Cox mailto:cox@idecnet.com