Marc Haber wrote:
>
> You can always drop in your own routers/transport without having to
> interfere with the debconf-driven mechanisms.
In my case, I found that for the vast majority of the files in
/etc/exim4/conf.d/, I was either not using the file at all (such as the
procmail/maildrop/etc routers), or I had to edit it. The number of
files that were useful to me unedited was quite small.
>>In many cases, they do. They just read them on exim.org, instead of
>>/usr/share/doc/exim4-*/.
>
> References to /usr/shade/doc/exim4-base/README.Debian are all over the
> place. We have even changed spec.txt to refer there.
You haven't changed the one place that most exim users look first for
documentation:
http://exim.org/exim-html-4.50/doc/html/spec.html
>>The fact that the debian package needs so much
>>debian-specific documentation is part of the problem, IMO, not the solution.
>
> What's your proposed solution to the problem? If you bitch, you'd
> better have a clue about how to do things better.
That's not fair, Marc. You know full well that I'm a contributor, when
I can be, not a pointless bitcher. Grep the changelog.
My proposed solution appeared below in the same email, and I've been
suggesting it for a long time now: exim should not be Debian's default MTA.
Look, I'm not trying to attack you, and I'm not saying you're doing a
bad job. What I'm saying is that you're doing the _wrong_ job. In
fact, I think the existing packaging (especially the debconfiscation) is
fantastic for the user who doesn't know anything about SMTP or MTAs and
just wants email to work when they install a new debian box. Most of
the time for this user base, for most use cases, It Just Works. The
debconf questions make configuring most of the things usually configured
by newbies easy to set, without touching any config files (the one
important thing that's missing from debconf, maildir, is understandable
given how you got screwed by the long debconf translation freeze). And
for the expert user who knows a lot about how both exim and dpkg work,
your package makes it easy for me to tell the debconf and dpkg stuff to
get out of the way and let me configure exim the way I want, which is
really all I can ask.
But between those two user groups is a large group of people who are
making the transition between clueless newbie and expert. IMO, the
current exim package makes things _harder_ for those people, by cutting
them off from their most valuable resource, this list (and all the
online doc/faq/wiki material that goes with it). You have to admit this
is true -- you've gone to great lengths to discourage your users from
contacting this list, or reading the publically available docs, but
instead using your own mailing lists and reading the exim-specific docs
you install with the package.
I don't believe it's possible to effectively target both groups (the
people who don't know or want to know anything about MTAs, but still
want to run one, and the people who know little but are trying to learn)
simultaneously. Broad debconfiscation is _required_ for the first
group, and an impediment for the second group. So you have to choose
between them. Because exim is the default MTA, you're forced to choose
the former. In my opinion, however, it's much more valuable to target
the second group; they're the ones who are likely to evolve into expert
users, and from there, into contributors to both the package and exim
itself. By targetting the people who want to learn, the entire
community benefits.
So, to summarize, my suggestion remains: something else should be the
default MTA, targetting the people who just want mail to work, and don't
need a fully featured MTA. My previous suggestion was ssmtp, which you
pointed out correctly isn't appropriate. I don't know what the right
default MTA is, but I remain convinced that it's not exim.
> Which parts of our configuration can be performance impacting? And how
> many of them might impact performance so that it becomes relevant for
> an end-user desktop system?
Sheer size of the config was what concerned me here. In particular, you
define a number of routers that are inactive in most installations, but
still get parsed on every invocation and checked for every message, such
as hubbed_hosts, dnslookup_relay_to_domains, procmail, and maildrop.
This is ignoring the routers that are defined but .ifdef'd out, such as
hub_user, hub_user_smarthost, nonlocal and smarthost; in those cases,
they don't get checked for every message, but they still introduce parse
inefficencies (likely negligable, I know) and more significantly,
daunting complications in the config files for the
newbie-who-wants-to-learn.
The other file that really concerned me most was
31_exim4-config_rewriting: it contains both a rewrite rule that's always
active, even if it's a no-op in most cases because /etc/email-addresses
is empty by default, and a black-box debconf macro that can't be edited
or learned from by the newbie-who-wants-to-learn.
[Re my statement about debian shipping "relatively immature x.x0 versions"]
> Actually, you should say "next to never".
After reading Andreas and Philip's replies to this thread, I went back
and looked at the exim changelogs; it turns out I was just plain wrong
on this point, and historically, x.x0 has not in fact been any less
mature than x.x5. In fact, with the updated spec file, x.x0 could be
considered more mature than x.x5. So I officially retract and apologize
for this statement. However, I want to point out that it was an asside
to the main point I was trying to make to the OP that Debian stable does
ship a specific frozen version for a very long period of time, and as
Andreas pointed out, the current release of Exim is almost always what
you want running on your mail server.
> Actually, in the last weeks before release, the release team was
> pretty cooperative. The reason I pushed for 4.50 in sarge was
> exiscan's integration in the upstream source because the Debian build
> process could be greatly simplified by removing the need to patch the
> upstream sources before daemon-heavy build.
My point about the release team was that they started talking about
imminent release long before they had an actual plan or achievable
schedule for it, which caused you to freeze your debconf translations
far too early and led to some unfortunate issues in the package.
> Please compare how many bugs I fix while I am saying "send a patch"
> once. Then reverse the ratio, and find the ratio valid for M'd.
Hey, I'm with you 100% on that one. That maintainer is the primary
reason I'm not running udev on my machines currently. I really like the
idea of udev, but I don't trust him to maintain the package properly.
Linking to that message was a joke.
> That's not a problem. Debian has committed itself to keep the exim in
> a stable release useable, as we did with exim 3, and still do. The
> same will go for exim 4. Additionally, Andreas is already offering
> "official" sarge backports of later exim4 packages. These are
> prominently linked from the Debian exim4 web page.
And I mentioned to the OP that the problem was solvable, if he was
willing to do one of a number of things, including updating exim from
backports.org (which really should link to or host Andreas' packages).
BTW, it took me five tries to figure out what you meant by "the Debian
exim4 web page". Places I tried first:
http://www.debian.org/exim4 (doesn't exist)
http://packages.debian.org/stable/mail/exim4
http://packages.qa.debian.org/e/exim4.html
http://pkg-exim4.alioth.debian.org/
before I finally got to:
http://wiki.debian.net/?PkgExim4
> Debian has always been a distribution for people wanting stability,
> and has always not catered well for version number junkies. That's a
> feature, and not a problem.
It's a feature if it's what you want, and you make an informed decision.
I was trying to inform the OP so he could make that decision with his
eyes open.
I don't want to start (or fan, if I've already inadvertently started) a
flamewar here. So I'll let you have the last word on this thread.
- Marc
