Attached php-config.diff for changed to php-config. Only as a solution to post installation.

No: This directory should always depend on the PHP API-Version (20041030 in this case). You really don't want extensions for different API-Versions share the same directory!

Why do you wan't do change the value?

Jürgen

It just seemed ugly having modules in different locations like that.
*shrug*
I assumed that php-config would return the location that modules are IN. There are currently no modules in the directory that it returns. All modules are in the other directory.
You have to load them by hand from php.ini regardless, so a php upgrade would still yeild incompatible modules being loaded, and the user would be forced to fix it. I see your point in organization though.
Guess this is one of those things I will just do on my own. No need to push it upstream then..
you can remove/close the bug.
thanks.

Added a fix for the next build.

Re-opened by request from Jürgen Hötzel

There is some kind of obfuscation about "extension_dir" i want to clarify:

1. PHP ships a default configuration-file (php.ini) which contains
extension_dir = "/usr/lib/php". Regardless of what you specify
during the build process, because this file is not auto-generated.

2. The default value (if you comment out the entry in php.ini) is:
"/usr/lib/php/extensions/no-debug-non-zts-20041030". This is still
the case with the current PKGBUILD because EXTENSION_DIR isn't set
during the build process.

-> set EXTENSION_DIR before you execute the configure script. The
php-config will be auto-generated correctly and the default value
for extension_dir is also correct. Patch attached.

I don't think it's a good idea to mess with these directories.
The API version stays the same across some releases, but once the next major PHP version (5.1.0 for example) is released, you will get into trouble with old modules with the new PHP. If we had done this with php4 already, we would have gotten bugs like "Help! PHP segfaults after upgrade!", while the actual problem would be an old self-compiled module then.

I don't see why people would be arguing against the improvement. If you do not update your php.ini file, then you would still be loading the modules from the wrong version regardless.
extension=extensions/no-debug-non-zts-20041030/modulename.so

This will still cause an error on version change, because they have to have the path explicitly provided. All you are doing is spreading them across directories needlessly. At the end of the day, the user will still need to update the modules they have hand compiled anyway. In fact, it makes it more difficult to add modules properly, because you have to know which subdirectory they are put in, instead of just knowing the module name.
extension=modulename.so

I like Jürgen Hötzel's patch. Can we get this added?

extension=extensions/no-debug-non-zts-20041030/modulename.so
extension=modulename.so

If the extension path in PHP is set up correctly, then every installer and every PHP instance will find this path without problems. The zend optimizer finds the correct path on all my debian machines and php loads the correct extensions from the correct path without giving any dir, just the plain modulename.so works fine, because the extensiondir compiled inside PHP is the first place looked in by PHP.

Mangling this extensiondir is not an improvement at all.

But on the arch install, all the modules (like mysql.so) are already in the /usr/lib/php dir. And extension is set to /usr/lib/php in the /etc/php.ini file. So, when adding an extension to the /usr/lib/php/extensions/no-debug-non-zts-20041030/ directory, they do not get included by simply adding extension=modulename.so in /etc/php.ini.

The argument was that upon a version change, the module would error when loading if it wasnt updated as well. Even if the extension dir was /usr/lib/php/extensions/no-debug-non-zts-20041030/, the user has to specify it manually anyway.
They must place extension=extensions/no-debug-non-zts-20041030/modulename.so in /etc/php.ini, so it gets loaded regardless. the error still occurs, but now there is an extra file structure the user has to deal with, for no reason at all.

Either the extensions dir needs to be specified (or commented out so the default is chosen) as /usr/lib/php/extensions/no-debug-non-zts-20041030/ in /etc/php.ini, and all the current modules should be moved there, or the inverse should occur..with all the modules being left in /usr/lib/php, and having the extension dir point to there.

This "little bit of each" is simply causing hassles for pkgbuilds that install modules (like eaccelerator).

we really should leave that path alone ...
done so in 5.0.5 and later