Ed Ravin wrote:
Ardo van Rangelrooij writes:
I've taken a different more flexible approach (based on what's become common practice in the Debian GNU/Linux distribution: I've created a directory called 'syslog-ng.d' [...]
Each sniplet has a name of '<digit><digit><sniplet nmae>' [...] cat syslog-ng.d/* >syslog-ng.conf upon a start and reload.
It's nice to be flexible, but I think the init.d paradigm, which relies on tricks of alphabetical filename sorting to enforce order at the expense of readability and managability, should be retired, not expanded.
If you're talking about managability the method I presented is favourable above changing a file just to add an #include statement. I prefer not to have tools changing configuration files during package install/removal, unless there's a wrapper available that does that on behave of the package (like using `adduser` instead of accessing /etc/passwd directly).
The joy of syslog-ng is that it has a clean, readable, and predictable configuration file. An extension for reading in include files would hopefully preserve those attributes.
You've lost me. If you use #include statetements your syslog-ng.conf could look like this: #include header #include global_options #include syslog-ng_internal #include source_localhost #include app_A_logging #include app_B_logging Wow, I'm impressed with the readability we just achieved. If I do an `ls' in my syslog-ng.d directory I see more or less the same. No matter which partitioning scheme we want to use, it all comes down to a proper organization of the configuration and keeping things together that belongs together. I'm also in favour of adding functionality to syslog-ng which is already available in cpp, m4 and other similar tools. I'm in favour of the UNIX style of small tools working together each doing it's own dedicated task. And how far do you want to go? Nested include's? Why then not simply use cpp as a preprocessor? Thanks, Ardo