[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org

On Thu, 2005-02-17 at 14:24 -0800, Blunt Jackson wrote:
> On Thu, 17 Feb 2005 19:31:20 +0000, Henning Makholm <henning@makholm.net> wrote:
> > Scripsit Blunt Jackson <bluujack@gmail.com>
> > 
> > > As a general note, I find it annoying, frustrating, and confusing
> > > whenever ANY debian package has a substantially different
> > > installation or configuratin mechanism than the mechanism documented
> > > by the software publisher.
> > 
> > Perhaps Debian is not the distribution for you, then.  We have always
> > prioritized constistency across the entire Debian OS over adherence to
> > what upstream authors somehow chose to do.
> Obviously there's a balance. I wasn't looking for flames. I believe I
> did explain *why* debian was my distribution of choice even so.
> > I maintain one package whose upstream author apparently thought that
> > $PATH would be a good place to look for a system-wide configuration
> > file. I changed that to look in /etc instead, which makes the
> > configuration mechanism in Debian substantially different from
> > upstream's. You may find this annoying, frustrating and confusing, but
> > it's how Debian operates.
> And clearly, *this* is a scenario in which the upstream author was way
> outside the *unix* standard way of doing things. I'm not saying
> there's any clear-cut answer, other than to hope that both upstream
> developers and debian package maintainers use common sense.
> One distinction is in applications that the majority of users just
> want to work out of the box, and forget about. If I had to tweak the
> configuration of every application on my servers, I would be a
> frothing maniac. But there are some biggies, some very well known
> applications, that, when installed for any practical purpose,
> generally require somewhat sophisticated user oversight. Exim is one,
> Apache is another. Mysql is a third. I put in the time to figure out
> the debian way of doing Exim (and I'm still not sure I understand it,
> but at for now I have it working). There was a substantial amount of
> hair pulling and cursing due to the disparity between what I saw on my
> hard drive and what I saw in the online documentation.

Okay, then generate the "old fashioned"Huge config file with
--keepcomments and If you don't remove the banners for each file you
will know which on the baddy.

Also, if you need to re-order the routers (the only one out side of
routers that need ordering is acl) then it is easy to do by simply
changing the number/letters at the beginning of the files name.

I DO NOT see what is so different from /etc/exim4/exim4.conf as compared
to /var/lib/exim4/config.autogenerated, especially if you use
--keepcomments. there really *IS* no difference. The pieces are just
packaged in small manageable ones to aid in the updating of.

Docs especially are like that Phil Hazel doesn't update them every time
he bumps the release. Marc Haber and Andreas Metzler are doing a great
job with exim.

>  After that
> experience, when I installed apache and mysql, and saw they were doing
> their own thing as well, I decided I didn't want to learn go through
> the same frustration with applications I already knew pretty well. I
> removed the debian packages, and compiled my own from the upstream
> developers. Note that removing the debian packages did not remove all
> their config files and so forth, there was a fair bit of manual
> cleanup afterwards -- but I'm not using the stable distribution, so I
> don't expect perfection.
> As for you, Florian's snide comment:
> > Just because the configuration file is called /etc/exim4/exim4.conf
> > instead of /usr/exim/configure?  Oh dear.
> No, it was the stuff like this that made me pull out my hair:
> domainlist local_domains = DEBCONFlocal_domainsDEBCONF
> How do I figure out where that DEBCONF stuff is coming from? What it means?

When you use "update-exim4.conf --keepsettings" the generated fully
populated  is available at /var/lib/exim4/config.autogenerated.

Also, any debconf setting are in the file:


things like DEBCONFlocal_domainDEBCONF is changed to the setting(s) in
that file. Also, one other thing, look at the main directory in the
config... it has about 3 files in it. Those three files are the
important ones that define "default actions" for exim to take. Many of
those are also can be managed by debconf as well.

> Of course, it didn't help that during the install I didn't quite know
> what I was doing, so based on the advice of the install program I
> chose the big-file-install, which *was* what I wanted, but I forgot
> that I had done that, so when I went to look at the exim config and
> found, as the exim website told me I would find (because I was on
> debian), a gazillion little bitty config files, I got started figuring
> them out, editing them, and not realizing why it made no difference.
> Suggestion to exim package people: if someone chooses the big config
> file, don't even install the little ones.

Why does it matter if they were installed or not? They weren't being
used. So you want Yet Another Package like:


> Anyway, the point was not to complain about exim... it sounds like
> other people are doing that somewhere else. The point was that
> *whenever* debian package maintainers re-implement a well-known
> distribution/config system, I *hope* that when users have to work with
> it they will discover, as I am sure anyone using Henning's package
> will, that the changes are clearly necessary -- an indisputable
> improvement.


> Now... my apologies for that interlude. I'll go back to lurking now.


> I promise I won't respond to any further condescending comments.

Oh, come on this *IS* Debian-Devel after all.

Over all the making of good stuff, means manageable. Debian use debconf
for the majority of things, SuSE uses Yast2, RedHat use 4500 little

Others do it other ways.

The bigfile *IS* created, just not where you expect it to be.
greg, greg@gregfolkert.net

The technology that is
Stronger, better, faster:  Linux

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: