On Tue, 20 Sep 2005 12:26:15 -0400, Marc Sherman
<msherman@???> wrote:
>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.
You can always drop in your own routers/transport without having to
interfere with the debconf-driven mechanisms.
>> 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-*/.
References to /usr/shade/doc/exim4-base/README.Debian are all over the
place. We have even changed spec.txt to refer there.
>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.
>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.
You're free to do that decision. But, please, don't discourage newbies
from using the things that we came up with. There is actual brain work
inside there.
>and did not contain some rather complex (and
>potentially performance-impacting) sections of Debian customization that
>were unnecessary in my installation.
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?
>> 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".
Actually, you should say "next to never".
>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.
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.
>
>> 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
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.
>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.
I disagree here. We have a fair share of users on dialup, and using
ssmtp on a dialup line _WILL_ lose mail since ssmtp doesn't queue at
all. ssmtp is fine for a host which has a 24/7 smarthost cluster with
five nines of availability on the local LAN, but a queueing MTA is
necessary for the default install.
>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.
The majority of dumb newbie questions come from people who don't have
a clue about e-mail but want to run a publicly available, multi-user,
probably commercial server on the Internet with even more features
than the feature set that we offer with the default install.
>[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'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.
> 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).
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.
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
