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

[Marc Haber]

On Mon, Dec 12, 2005 at 02:03:35PM -0800, Ross Boylan wrote:
> Sounds good.

Changes committed to svn.

> Alternately, just move the whole discussion to benefits
> of unsplit.

As someone who likes split more, I won't do that ;)

> 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?

No, and if there would be one, using it in a maintainer script of a
non-exim4 package would be a policy violation and an RC bug. Package A
cannot modify package B's dpkg-conffiles in its maintainer scripts.

> A truly ambitious package writer might want to work on automatically
> updating the unsplit config,

No, that's forbidden.

> Simplest is for the package to print/mail/have in the README a warning
> that you must manually edit the exim config file.

That's about all that's possible.

> Or exim could
> provide some script that attempts to merge stuff into the unsplit
> config.

That script is already there. It is update-exim4.conf.template.

> 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.

That might happen, and would be a bug in the other package.

> 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.

Explain. I cannot imagine a situation like that. If the local admin
uses update-exim4.conf.template, she decides to overwrite
exim4.conf.template consciously. In the other cases I can think of,
things either don't work at all, or work and live over updates.

> 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).

Yes. But it is a conscious thing to activate the new configuration,
and thus the breakage is immediately noticed. Andreas was concerned
about some random package dropping broken and incompatible config into
the split directory, and exim would fail on next config reload, which
could be days later.

> 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.

Please suggest a less harsh wording. I am a big friend of the split
config, and nonsplit wouldn't exist hadn't Andreas insisted, so I'm
all in favor of letting split look better ;)

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835