Re: [exim] Debian as a 'Special Case' for Exim

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.

> otoh, there is no requirement that the package providing exim4-config
> needs to be maintained by the Debian exim4 maintainers. Care to join
> us?

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

> That sounds like a nightmare from the maintenance point of view.

I don't think so. You could set it up so that the source package still
contains all the same configs you currently ship. The only difference
would be that instead of running the template engine at launch time to
generate /var/lib/exim4/config.autogenerated, you run it at build time
to generate the different exim4-config-* packages. As maintainers,
you'd still only have one set of split configs to edit.

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

> All our MTA packages interact on installation.

That's true. But IMO, the default MTA should be held to a higher
standard.

> 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. There's a very large group of users who won't undertand that, and
they will generate a lot of traffic on this list once Sarge ships. I'd
hate to see the kind of anti-Debian sentiment we've had on this list for
the Woody cycle continue for another 3 years, just when we're about to
solve the "Debian ships exim 3 by default" problem.

Speaking of which... Philip's getting ready to release 4.50 tomorrow, so
it must be time to push 4.44-2 into testing. :)

- Marc