[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#224828: Split config file is worrying...

Anthony DeRobertis <asd@suespammers.org> wrote:
> [ Yes, I know about the /etc/exim4/exim.conf override, and I'm using
>  it. ]

> I wish the split-out config file would go away. I have read the
> rationale for it in README.Debian, and, honestly, those sound like
> drawbacks!

> For simple configurations such as with just debconf, you won't touch
> anything in /etc/exim4. Or, if you do, the changes will be very small,
> and merging the changes will be trivial. And upgrades will be infrequent
> (with stable releasing every two years or so). So the first bullet
> point, "it means less work for you when upgrading" seems to not apply to
> these users.

The point "upgrades will be infrequent (with stable releasing every
two years" is the main one. If you are running stable merging in the
changes every two years is indeed no big issue, OTOH if you are
running unstable or testing merging in two one line patches into a
40KB file every month would be a real PITA.

With conf.d small changes e.g "untrusted_set_sender = *" and addition
of rewrite rules won't _ever_ require merging. - And *small*
modifications like these will be found on many systems.

> For more complicated configurations, those changes --- possibly even
> including new or removed files --- happening without ANY prompting and
> any chance to merge your changes --- is very worrying. It seems quite
> likely to break things. Honestly, with how likely it is to break
> something, I believe it goes against the spirit of Policy 10.7.3.
> Because of this, people like me who are making extensive changes to the
> default config can't use the split-out config.

Agreed. split-out config is great for modifications and extensions of
a configuration, i.e. by adding personal rewrite rules or adding a
mailman router or disabling a router (by removing the file or using a
.rul). If you are making *extensive* modifications conf.d looses.

> As to the second point, that seems likely to break things, too. exim
> config files are too inter-dependent to have random packages adding
> things in. It'll probably work with the debconf defaults. I doubt it'll
> work with much else.

Depends. e.g. sa-exim is orthogonal to normal exim configuration, or if
"deliver" contained a router and transport for using it as MDA it is
unlikely to break anything else.

I am willing to resurrect /etc/exim4/exim4.conf.template as alternative
to conf.d (dumped in 4.12-0.0.6). - The file would also be a
dpkg-conffile and would contain the result of
find exim4/conf.d -type f -print0 | xargs -0 cat
in our CVS. There'd be medium debconf question asking whether
update-exim4.conf should use the template file or the conf.d
hierarchy to generate config.autogenerated. The question would default
to yes for fresh installations and no for upgrades.

Template: exim4/use_split_config
Type: boolean
Description: Split configuration into small files?
 The Debian exim4 packages can either use one big monolithic file
 /etc/exim4/exim4.conf.template or about 40 small files in
 /etc/exim4/conf.d/ to generate the final configuration.
 The former is suited better for big modifications and is generally
 more stable, the latter offers a comfortable way to make smaller
 modifications but is more fragile and might break if modified
 If you are unsure you should not use split configuration.

As I am no native speaker I welcome corrections.
                    cu andreas
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_

Reply to: