On Thu, 17 Feb 2005 11:25:47 -0500, Marc Sherman
<msherman@???> wrote:
>Marc Haber wrote:
>> Install exim4 with debconf non-interactive frontend, and that's quite
>> exactly what you get.
>
>That's a red herring. The problem isn't the interaction itself, it's
>the complex structure of the resulting config directory needed to
>support the interaction.
>
>My proposal was to install a simple config file by default.
This would be something we have never done. It will cause gazillions
of bug reports since we install a _very_ restricted configuration by
default which is _very_ hard to change.
>You know, if you would agree to change the depends of exim4-base from
>"exim4-config" to "exim4-config-localonly|exim4-config", I would happily
>work on providing a patch to the exim4 source package to generate
>exim4-config-localonly (and possibly additionally
>exim4-config-monolithic and exim4-config-split), or a seperate package
>if you'd agree to sponsor it.
I would agree to sponsor it. There are no change in the exim 4
packages needed. To have your package seamlessly integrate, you only
need to follow directions given in
/usr/share/doc/exim4-base/README.Debian.gz in the paragraph titled
"Using a completely different configuration scheme". The source
package even has infrastructure to generate a skeleton
exim4-config-custom package. Maybe, debian/exim4-config-simple is
pretty near to what you want.
>I'm not sure it's worth it at all if we can't convince the RMs and
>ftpmasters to allow it in Sarge, though -- the whole point is to avoid
>another 3 years of this pain. I think we could make a very convincing
>argument on debian-release, but only if you and Andreas were solidly
>behind the idea.
I am not yet convinced and think that we might be in for three years
of _other_ pain. Having an actually maintained exim4-config-simple in
Debian (priority optional or extra which is not yet frozen) would be a
good way to satisfy expert users who don't want to see the magic. For
the default install, I am afraid we'll have to stick with the magic.
Maybe discussion on debian-devel might give information what other
people and the release team think.
>> Additionally, today, $OTHER_PACKAGE can drop whatever transport and/or
>> router it needs into the directory structure and both versions of the
>> current config can pick that up (single-file on explicit request, and
>> many-file on next daemon restart).
>
>That would still work just fine. If exim4-config-localonly was
>installed, there would be no /etc/exim4/conf.d directory. When a
>third-party package is installed that includes a conffile such as
>/etc/exim4/conf.d/router/850_my_mailfilter_of_the_week, dpkg will create
>the conf.d and router directories, and the user can add the .include
>statement to their exim.conf. Given that the current debconf config
>recommends answering "no" to the "use split configs" question, that
>package has to document how to add the manual .include already, so
>nothing's really changed.
If you use non-split config, the idea is to manually run
update-exim4.conf.template to regenerate the template from the split
config. No .include needed. Actually, the split config scheme was
invented at a time when there was no .include. Philip was a little
slow in fulfilling that wishlist request ;)
>> All our MTA packages interact on installation.
>
>That's true. But IMO, the default MTA should be held to a higher
>standard.
A higher standard by offering no configuration options at all? I
strongly doubt that is practicable.
>> We are compatible with upstream by means of a manually created
>> /etc/exim4/exim4.conf. A lot of the "big" packages differ from
>> upstream's configuration scheme, apache being one of the most
>> prominent examples.
>
>Sure, you _support_ upstream-style configs. But you don't default to
>them.
Yes, because using them requires skill which we cannot expect from the
majority of our users.
>Speaking of which... Philip's getting ready to release 4.50 tomorrow, so
>it must be time to push 4.44-2 into testing. :)
That request has gone out to -release this morning, and since the
development svn does not include upstream sources any more, 4.50 will
be in experimental quite fast. The experimental step is still required
since we still don't have testing-proposed-updates *sigh*.
Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
