On Tue, Oct 27, 2009 at 11:06 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> IME, the use case for multiple Apache configuration files is that
> there are bits of configuration that support particular modules which
> packagers want installed only in conjunction with the corresponding
> modules - it has nothing to do with being able to automate config-file
> updates, or at least I am not aware that it does.
That sounds like automated config file updates to me. Individual
modules are being installed and uninstalled and automatically updating
the configuration to handle the modules.
It's also not just modules, it's things like virtual sites. So for
example in Debian if you install a package which includes a web
interface it installs a configuration file for that web interface
under the appropriate directory.
I don't see the problem Tom describes. Clearly there's a conflict and
the settings from one of the files will have higher priority than the
other, but at least the two sets of settings will be kept separate.
Neither module will have to deal with rereading its output to see if
it has been mysteriously changed by another program. A good tool might
still want to check the settings in the running database to see if its
file is the source of the current value to give the user feedback.
If they all had to edit the same file then they have to deal with
writing out values and also reading them back. Everyone would need a
config file parser and have to make deductions about what other tools
were trying to do and how to interact with them.
I didn't realize Apache supported wildcards, and looking at Debian's
run-parts it looks like it's more liberal than I realized (though
still more conservative than the *.conf people keep insisting on). I
still think a simple hard coded rule is more useful and than allowing
sysadmins to specify any regexp or glob and then having modules or
tools not know what's allowed or not.
--
greg