Re: Bug#224828: Split config file is worrying...
On Wed, Jan 07, 2004 at 09:42:10PM +0800, Cameron Patrick wrote:
> Andreas Metzler wrote:
> | On Wed, Jan 07, 2004 at 07:33:41PM +0800, Cameron Patrick wrote:
> | > Could you avoid the debconf question and use a similar mechanism to what
> | > the current XFree packages do: generate the file from conf.d, unless its
> | > md5sum has changed from the generated version. That way you don't need
> | > to have a debconf question, and when someone edits their exim4.conf
> | > file, exim Does The Right Thing and doesn't scribble all over it.
> | I don't want to dump conf.d, I want to keep it around.
> Yeah. But you were proposing a debconf question to allow users to
> choose between conf.d and a monolithic config file; my suggestion was
> that the debconf question was unnecessary and that a better way of
> finding out whether or not the user wants to use a monolithic
> configuration by seeing if they've edited said config file by hand.
I want to allow people to choose between monolithic and split, and
therefore need to safe this informatin in
/etc/exim4/update-exim4.conf.conf to modify update-exim4.conf's
behavior accordingly. I can either hide the option in the file or make
it _also_ configurable via a debconf question (of yet to be decided
> The logic would look something like:
> - have an /etc/exim4/exim4.conf.template as you described
> - compare the md5sum of /etc/exim4/exim4.conf.template with an md5sum of
> the last automatically generated version.
? I don't have a last generated version of exim4.conf.template - it is
newly introduced file.
> - If they're different, copy the admin's exim4.conf.template to
> /var/lib/exim4 rather than looking in conf.d. The admin could perhaps
> force the use of conf.d by running update-exim4.conf, if that was
> ever necessary later. Don't update the stored md5sum.
There is no "admin's exim4.conf.template" yet.
> - Otherwise: update-exim4.conf should generate the config file in
> /var/lib as it does now, and also generate an /etc/exim4.conf.template
> (with comments kept in it) so that if the admin ever wants to make
> wholesale changes and throw away conf.d, this can be done easily using
> the current configuration as a base. Update the stored md5sum.
The whole point of /etc/exim4/exim4.conf.template is that it is _not_ a
generated file but a dpkg-conffile, update-exim4.conf *may* *not*
The only thing I think of is to run
find /etc/exim4/conf.d/ -type f -print0 | xargs -0 cat | md5sum
and compare its results with the known md5sum of the newly introduced
file and default to monolithic even for upgrades if they match.
However I don't want to do that because the config script is usually
run two times and the generated md5sum will differ because the first
runs before the new conf.d is unpacked while the second one runs