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

[Ross Boylan]

On Sat, 2005-12-17 at 16:01 +0100, Marc Haber wrote:
> 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 ;)
I don't see how leaving a discussion of the drawbacks of split in the
section on the split configuration makes it look better.  Oh, my
original remark may have been unclear.  "whole discussion" referred to
the discussion of the fragility issue, which in the draft is split
between a section under split config (how it is fragile, a drawback) and
unsplit (how it is less fragile, an advantage).
> 
> > 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.
I'm thinking of the case where the user/admin
crafts /etc/exim4/exim4.conf.  My guess is that is not a conffile for
exim4, since the package doesn't even create the file by default.
Also, I didn't know the rule about packages not modifying each others'
confiles; I figured if a user can do it, why not a package?
> 
> > 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.
Again, I'm thinking of an exim4.conf.
> 
> > 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.
Having studied things more closely, I think this could only arise out of
poor administrative practice.  The scenario I had in mind is
1) someone has their own exim4.conf file, perhaps created by copying the
autogenerated file and then modifying it.
2) A non-exim package modifies exim4.conf under my imagined scenario
above where other packages update the unsplit exim4.conf if it's there.
3) Admin attempts to recreate exim4.conf from the automatically
generated files.

The problem is that step 3 is kind of silly anyway, since it would
remove all customizations that had been applied.

I think this does show that even if a packages modifies the unsplit
file--and it's not clear that's a good idea--it should still drop in the
little configuration snippet for conf.d.

Additional complication: conf.d may not be present, since that depends
on the decision to use exim4-config.

Somehow, I doubt I'm helping here :(  Maybe better luck with the next
issue.
> 
> > 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,
I don't follow what "activate the new configuration" means.  Is it a
reference to using the split config at all?  Or to the new configuration
induced by the other package?
> 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.
Is the premise of this concern that a new package will drop something
into conf.d but do nothing that would affect the unsplit config
(including modifying the template), whether autogenerated or purely
hand-crafted?

If so, the concern seems to be more with the dangers of automatic
updates of the configuration than whether it's split or not.  However,
since the unsplit doesn't get automatically updated (if my
interpretation is correct), it comes out safer.

If this interpretation is correct, then the split configuration has a
feature (updates from other packages automatically incorporated) which
is simultaneously a plus and a minus (good that it's automatic; bad that
it might break).
> 
> > 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 ;)
First I need to understand exactly what the fragility issue is about.  I
understand that something like a double definition will mess things up;
I'm not sure why that is less likely to happen (or be easier to debug?)
in the unsplit than the split case.

I presume if you run update-exim4.conf.template you have about the same
problems as a user of unsplit, except that it's probably easier to
notice the double definition when both definitions are in a single file.
> 
> Greetings
> Marc
> 
-- 
Ross Boylan                                      wk:  (415) 514-8146
185 Berry St #5700                               ross at biostat.ucsf.edu
Dept of Epidemiology and Biostatistics           fax: (415) 514-8150
University of California, San Francisco
San Francisco, CA 94107-1739                     hm:  (415) 550-1062