Re: exim4-config and exim4-base installed on systems with non-exim-MTA
* Tollef Fog Heen
> It also makes it possible for packages such as clamav, spamassassin
> and mailman to seamlessly drop in support in a fairly clean way.
Which (possibly) makes the configuration break in a whole new way, if
you decide to actually change the logic of stuff inside conf.d/.
Suddenly you have a new spamassassin/clamav/whatever router inside
the concatinated configuration that makes Exim route your email
somewhere it shouldn't.
As far as I know there is no way of telling the Exim packages "do not
modify my customized configuration without asking me" as usually is the
default elsewhere in Debian (and "configuration" here is of course the
complete configuration as used by Exim, not the individual files in
conf.d/), short of ignoring the Debian-provided default configuration
entirely, by using /e/e/exim4.conf or setting conftype to none.
* Tore Anderson
> The Apache 2 packages does much of the same, sadly.
* Tollef Fog Heen
> For the same reason, mostly.
The good thing about the Apache 2 packages is that my resulting
configuration won't be changed merely by downloading a new package
(for it will put its snippet in the -available directories). They
don't split the configuration suff out from the -common/-base package,
either.
The -enabled directories/symlink farms and /etc/vhosts/* stuff is
what's seems a tad strange and excessively Debian-specific to me; I
have preferred if the reccomended way for packages was to drop their
example httpd.conf snippets in a single, standardized directory, and
then the standard way of enabling these would be to simply Include
them from the main httpd.conf. KISS and all that, y'know.
But that's anyway just aesthetics to me. Just ignore my ranting
until I submit patches or constructive suggestions. (I certainly
would, if I were you. :)
--
Tore Anderson
Reply to: