Re: Sendmail woes (was: make anacron a base package)
"Steve Lamb" <morpheus@rpglink.com> writes:
> On 31 Mar 1999 17:25:41 -0600, John Goerzen wrote:
>
> >> According to the accepted definition, it is.
>
> >How can something be drop-in if it doesn't understand the existing
> >setup and can't provide the same services as the existing item? I
> >don't think that any definition allows a "drop-in" to be incompatible
> >with the existing setup.
>
> The accepted definition of "drop-in" is that the program offers all the
> functionality to other programs on the same system as the previous offering
> did. This is the defitinion that has been in use for years when related to
> many different programs. It has *NEVER* refered to using the same
> configuration files.
And as I have pointed out numerous times already, exim does not offer
all the same functionality as sendmail. In fact, I said that above --
"can't provide the same services as the existing item." Really, this
selective reading that you are doing, Steve -- purposely ignoring the
parts of my message that you can't find a good rebuttal for -- is
getting annoying.
> >> No, it isn't.
>
> >Why not?
>
> Because .cf *IS* and a good portion of cf is still in m4. To be able to
> fully configure Sendmail one *must* know cf.
In order to configure Sendmail to the same extent that one can
configure exim, one does not need to know cf. I, in fact, know little
of .cf -- only the parts that map directly from m4 to it, in fact, and
none of the rewrite rules. My mc file does not now, nor has ever,
include any raw .cf lines. Just what can you do in exim.conf that cannot
be done with sendmail.mc?
> >> It certainly isn't an improvement of cf, that much is certain.
>
> >And why is that?
>
> See above. It is just another layer of abstraction trying to hide how
> hidious the configuration really is. m4 is like Win31 was to DOS. Just
> because you know Win31(m4) doesn't mean you know DOS(cf). And tell me,
> which one does Sendmail read DIRECTLY. CF. Thank you, case closed.
Which is still irrelevant that it's a layer of abstraction. Guess
what. C is a layer of abstraction above assembler, which is the same
above machine language. Perl is layer above C, on top of that. This
does not immediately make all Perl programs "evil".
Furthermore, many programs have a module for config-file parsing
linked in. Why does it suddenly turn evil because one step of parsing
is done by an external program?
> >How is somebody going to find out, or care, that m4 is being run back
> >behind the scenes someplace?
>
> When it fails to do what they need or when it breaks.
m4 is not buggy. You have yet to produce even one example of
something that can be done in exim.conf and not sendmail.mc, much less
a bug in m4 that prevents sendmail.mc from working.
Reply to: