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

[Ross Boylan]

On Sun, Dec 11, 2005 at 09:12:15PM +0100, Marc Haber wrote:
> On Sun, Dec 11, 2005 at 02:45:10PM -0500, Faheem Mitha wrote:
> > 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'?
> 
> You have a point here. Done.
Sounds good.  Alternately, just move the whole discussion to benefits
of unsplit.

However, this raises some issues about split/vs unsplit configs.
Apologies if this has already been discussed.

1) There should be some advice for maintainers of other packages that
want to drop in snippets to the conf.d.  In particular, what should
they do if the configuration is unsplit?  Is there a debian helper
macro?

A truly ambitious package writer might want to work on automatically
updating the unsplit config, but that seems like a lot to ask.
Simplest is for the package to print/mail/have in the README a warning
that you must manually edit the exim config file.  Or exim could
provide some script that attempts to merge stuff into the unsplit
config.

Conversely, perhaps there are some old packages, or old package
instructions, that will update the unsplit config file even if split
config is in use.  (Or do the different file names assure this won't
happen?).  I could imagine that leading to a frustrating situation
where things work for awhile and then, when the config is regenerated,
they stop working because the changes get overwritten.

2) I know the "fragility" referred to above has been cited as a
drawback of split, but I'm not sure how distinct it is to split.  If
someone merges some code into an unsplit config, it could easily have
the same problem (e.g., double definition of macro).  Is the issue the
likelihood of the problem, or the difficulty of noticing the
duplication if you have an unsplit config?  I'd call the latter more a
debugging issue--not that that is unimportant.

The general remark about getting out of sync may be too strong; it
makes it sound as if the whole thing is likely to collapse at any
change.  It sounds a bit like the kernel; if I rebuild my kernel, I
must rebuild all the modules.  Extending this thinking to exim, every
package add on needs to be "built" or designed for a particular
version of exim.  I know that's not true, but I think it would be easy
for someone reading the text above to get the impression that it is
true.

I'd try to suggest some alternate language, but I'm not sure enough of
the importance of the debugging issue I raised earlier to know what to
say.

Ross