Marc Haber wrote:
I have to object about that. Most documentation and FAQ material only
quote a router, a transport or an ACL snippet, which is as easily put
into our configuration scheme as it is in a hand-crafted exim.conf.
The issue is that our exim is useable for people who didn't read a
line of docs, and simply don't know the difference between a router
and a transport. That problem would be there as well if our
configuration scheme would operate on a monolithic exim.conf.
Yes, I agree with you; the debconfiscation is actually more of an
impediment to reuse of existing documentation/faqs than the split config
is, IMO.
All people need is to read the docs. They don't.
In many cases, they do. They just read them on exim.org, instead of
/usr/share/doc/exim4-*/. The fact that the debian package needs so much
debian-specific documentation is part of the problem, IMO, not the solution.
Of course, the _really_ clueful people use the gazillions of hooks
that we provide to get their own customized config _and_ our updates
to the parts they didn't change.
You know full well that I made an honest attempt to use (and contribute
to) your packages and config mechanism the way you intended them to be
used for about a year. This is not a reactionary rejection of someone
who installed the Debian package, saw all the debian-specific stuff that
wasn't what he was used to, and threw his hands up in disgust.
I, personally, found that the amount of effort required to integrate
updates into the many split config files with my own local
modifications, even during the relatively calm period while Sarge was
stabilizing for release, was not worth the benefits of using Debian
configs for the parts I hadn't customized. In the end, I replaced the
debian config files with a hand-crafted exim4.conf which was less than
half the size of the complete debian config file, much simpler for me to
understand in total, and did not contain some rather complex (and
potentially performance-impacting) sections of Debian customization that
were unnecessary in my installation. Of course, YMMV.
Debian potato had exim 3.12, Debian woody shipped with exim 3.35,
IIRC, which is hardly a "relatively immature" release, and Debian
sarge has 4.50 which works actually very well.
Sorry, I should have said "sometimes", not "often". There have been a
(small) handful of bugs fixed since 4.50 that have made me very glad I'm
not running stable. And for the record, you and Andreas are _not_ to
blame at all in my mind for this issue -- I tried to make it clear in my
first message that I think this is the release team's problem, not
yours. You guys got badly jerked around by the very early debconf
translation freeze prompted by the release team's promise of an
impending sarge release, over a year before sarge actually shipped.
Do you want to maintain the package? If we're doing really as bad a
job as you suggest, I'm happy to step back for you. Just say so.
http://lists.debian.org/debian-devel/2005/09/msg00921.html
:)
Seriously, no, I don't want to maintain the package. I think you're
doing a pretty good job at an impossible task. I don't think Debian
should have a fully featured MTA installed by default; something like
ssmtp would be much more appropriate by default, IMO. Then exim would
only be installed by people who actually want to use it, and are willing
to invest the time to configure it properly.
[snipped: my discussion of Debian's stable keeping old versions
installed for very long lengths of time]
Why will it be a problem?
Presumably if he's a subscriber to this list, he's keeping current on
developments in exim upstream, and will want to use them. That means
that the version of Exim that shipped in Sarge is a problem that he
needs to solve using one of the methods I suggested (installing
testing/sid, using backports.org, or building his own).
- Marc
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
