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
--
[EMAIL PROTECTED] 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/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
