For some time, PHP has had a build option

./configure --with-config-file-scan-dir=/etc/php5/conf.d/

that allows distribution maintainers to manage system-wide PHP
configuration by adding/removing individual files with configuration
fragments to this directory, for example when installing a package with
a compiled PHP an extension.  

This is an improvement over the previous situation where php.ini had to
be edited by package install/remove scripts.

On Debian and Ubuntu systems (and maybe others), each SAFI ie. apache2
module, cli, or cgi is compiled with a different location of php.ini and
config-file-scan-dir. (which is a bit redundant, with the option of
naming it php-cli.ini, php-apache2.ini etc.)  

Also, the config-file-scan-dir is set
to /etc/php5/apache2/conf.d, /etc/php5/cli/conf.d, which are then
symlinked to /etc/php5/conf.d, (also a bit redundant)

So it seems, it is easy to have system-wide settings in multiple
separate files, which is good for packagers, but per-SAFI configuration
must still be in *one* php.ini choosen from several locations in the
ini-search-path.

I wonder if the config-file-scan-dir could be a path with multiple
directories to search, then each SAFI could be compiled with a common
and a per-SAFI directory to scan.

It could be a loop around this part of main/php_ini.c around line 512:

        /* If the config_file_scan_dir is set at compile-time, go and
scan this directory and
         * parse any .ini files found in this directory. */
        if (!sapi_module.php_ini_ignore &&
strlen(PHP_CONFIG_FILE_SCAN_DIR)) {

The config-file-cscan-path could then
be /etc/php5/conf.d:/etc/php5/apache2.d
or /etc/php5/conf.d:/etc/php5/cli.d

Depending how much change is wanted/tolerated, this could get rid of the
other special cases that search for ini-files in a path, which searches
for php-$SAFI.ini, then php.ini, etc. since they could be put in the
config-file-scan-path.

-- 
Jeremy Jackson
Coplanar Networks
(519)489-4903
http://www.coplanar.net
j...@coplanar.net


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to