[Pkg-exim4-users] minor comment on exim README.Debian

[Faheem Mitha]

On Sun, 11 Dec 2005, Marc Haber wrote:

> I have re-worded the sections. What do you think about this:
>
>        Benefits of the split configuration approach:
>        <itemizedlist>
>          <listitem>
>            <simpara>
>              it means less work for you when upgrading. If we shipped
>              one big file and modified for example the Maildir
>              transport in a new version you won't have to do manual
>              conffile merging unless you had changed exactly
>              <emphasis>this</emphasis> transport.
>            </simpara>
>          </listitem>
>          <listitem>
>            <simpara>
>              It allows other packages (e.g. sa-exim) to modify exim's
>              configuration by dropping files into
>              <filename>/etc/exim4/conf.d</filename>. This needs, however
>              quite exact syncing between the exim4 packages and the other,
>              cooperating package.
>            </simpara>
>          </listitem>
>          <listitem>
>            <simpara>
>              It is more fragile. If files from different sources
>              (package, manually changed, or other package) get out of
>              sync, it is possible for exim to break until you
>              manually correct this. This can for example happen if we
>              decide to add a new option to the Debian setup of a
>              later version, and you have already set this option in a
>              local file.
>            </simpara>
>          </listitem>

You've got this 'more fragile' item listed under benefits. Maybe create a 
separate category here called 'Drawbacks'?

Drawbacks:

Is more fragile. ...

>        </itemizedlist>
>      </para>
>      <para>
>        Benefits of the unsplit configuration approach:
>        <itemizedlist>
>          <listitem>
>            <simpara>
>              People familiar with configuring exim may find this
>              approach easier to understand as exim4.conf.template
>              basically is a complete exim configuration file which will
>              only undergo some basic string replacement before is it
>              passed to exim.
>            </simpara>
>          </listitem>
>          <listitem>
>            <simpara>
>              Split-config's fragility mentioned above does not occur
>              with the unsplit configuration at the price of needing manual
>              intervention in case of an upgrade.

Perhaps move the last phrase out of there, "at the price...".

>            </simpara>
>          </listitem>
>        </itemizedlist>

Drawbacks:

Will require manual intervention in case of an upgrade.

A little verbose, but clear.

>      </para>
>      <para>
>        If in doubt go for the unsplit config, because it is easier to
>        roll back to Debian's default configuration in one step. If you
>        intend to do many changes to the Debian setup, you might want to
>        use the split config at the price of having to more closely
>        examine the config file after an update.
>      </para>
>      <para>
>        We'd appreciate a patch that uses ucf and the 3-way-merge
>        mechanism offered by that package. It might be the best way to
>        handle the big configuration file.
>      </para>
>
> If you find that acceptable, I'll commit it to svn.

Otherwise looks good.

BTW, you say in the README.Debian

************************************************************
If you chose unsplit configuration, "update-exim4.conf" builds the
configuration from /etc/exim4/exim4.conf.template, which is basically
the files from /etc/exim4/conf.d/ concatenated together at package
build time, and thus guarantees consistency on the target system.
*************************************************************

Are the files in /etc/exim4/conf.d really only concatenated at package 
build time? What about if a another packages adds a file to 
/etc/exim4/conf.d?

Thanks.                                                           Faheem.