Bug#301906: Re: Bug#301906: exim4: Mail messages sent to local addresses are lost

[Marc Haber]

Hi Vincent,

On Tue, Mar 29, 2005 at 11:52:16PM +0200, Vincent Lefevre wrote:
> On 2005-03-29 22:49:13 +0200, Marc Haber wrote:
> > On Tue, Mar 29, 2005 at 09:46:18PM +0200, Vincent Lefevre wrote:
> > > BTW, /etc/exim4/update-exim4.conf.conf says:
> > > 
> > > # Edit this file and /etc/mailname by hand and execute update-exim4.conf
> > > # yourself or use 'dpkg-reconfigure exim4-config'
> > > 
> > > so the user may think that he has the full control of this file,
> > 
> > He has, but it is generated by debconf. Debconf reads in the file
> > and takes the values from there during reconfiguration of the package,
> 
> and some changes by the user may be overwritten by a reconfiguration
> of the package.

Usually not. The code handling update-exim4.conf.conf carefully reads
in the settings before changes.

Our current issue is the other way round: update-exim4.conf.conf
correctly fixed up your configuration file, preserving all local
changes that it was able to see. And you overwrote the fixed code with
the output of your m4 script. I don't see what the exim4 configuration
can do here. I mean, for our code this looks like "ok, we fixed
dc_other_hostnames once, but the local admin decided that he didn't
like our change and undid it. Oh well." Actually, what you did was a
local change, and we are bound to respect that one.

We changed our default behavior, and adapted the configuration in a
way that doesn't change overall behavior. Your code undid our
configuration adaption, resulting in the application behaving
according to the new default.

> > but having multiple versions of the file replacing each other
> > depending on environment is pretty exotic.
> 
> It's pretty common for those who use netenv.

But done wrong.

> > I don't see what the exim4 packages can do within reasonable bounds
> > regarding to this particular problem without leaving a gazillion of
> > other possible error cases unhandled.
> 
> Comments should be clear about who can modify the files and how.

Anybody can modify update-exim4.conf.conf, and changes done locally
are respected. And you have proven that this works.

> If you want other examples, /etc/X11/XF86Config-4 begins with:
> 
> ### BEGIN DEBCONF SECTION
> # XF86Config-4 (XFree86 server configuration file) generated by dexconf, the
> # Debian X Configuration tool, using values from the debconf database.
> #
> # Edit this file with caution, and see the XF86Config-4 manual page.
> # (Type "man XF86Config-4" at the shell prompt.)
> #
> # If you want your changes to this file preserved by dexconf, only make changes
> # before the "### BEGIN DEBCONF SECTION" line above, and/or after the
> # "### END DEBCONF SECTION" line below.

This is much worse than what we do: dexconf unconditionally overwrites
what is in between the BEGIN and END line while we respect all local
changes.

> and /etc/fonts/fonts.conf begins with:
> 
> <!--
>         DO NOT EDIT THIS FILE.
>         IT WILL BE REPLACED WHEN FONTCONFIG IS UPDATED.
>         LOCAL CHANGES BELONG IN 'local.conf'.

So that file doesn't belong in /etc, it should be in /var. It is the
equivalent to our /var/lib/exim4/config.autogenerated


I have adapted our postinst to dump the following comment into
ue4.conf.conf:
# Please note that this is _not_ a dpkg-conffile and that automatic changes
# to this file might happen. This is usually fine, but will break local
# schemes that mess around with multiple versions of the file.

and exim4-config.NEWS has the following:

  * mailname, the local name of the system used to qualify senders and
    recipients is no longer a local domain by default. Having local
    delivery for that host name used to break satellite and smarthost
    setups where no local delivery was expected.
    /etc/exim4/update-exim4.conf.conf is modified automatically on
    upgrade from the appropriate earlier versions, so if you don't do any
    funky things with /etc/exim4/update-exim4.conf.conf, you should be fine.

This bug will be closed with the upload of these changes to unstable.
Please feel free to re-open it if you think that there is more that we
can do.

Greetings
Marc

-- 
Marc.Haber@syscovery.com              syscovery network services GmbH
Dipl.-Inform.                                    Weinheimer Straße 68
Geschäftsführer                                      D-68309 Mannheim
Tel: +49 [0] 621 71768 57                   http://www.syscovery.com/