Dumb, dumb, dependancies

[waltdnes-SLHPyeZ9y/tg9hUCZPvPmw at public.gmane.org]

  I use ssmtp to emulate sendmail forwarding to IStop's MTA.  The binary
is named (wait for it) "ssmtp", and there is also the option of creating
a symlink called "sendmail".  I did that once, just once.  That's when I
discovered that cron jobs can be very verbose, and send email to root.
Since ssmtp forwards to IStop's MTA, my cron job outputs started going
to root-Zd07PnzKK1IAvxtiuMwx3w at public.gmane.org (oops).  When they sent me an email saying "please
stop", I deleted the "sendmail" symlink.  Now mutt is configured to use
"/usr/sbin/ssmtp" as its sendmail-equivalant command and cron jobs don't
see a usable MTA.

  Fast-forward to August.  A few packages will not install on Debian
because the libs are so old.  A new, updated, stable release is due out
in a matter of weeks, but I use it as an excuse to try CRUX linux on my
2nd machine.  Everything's compiled "-O2 -march=i686".  The CRUX "ports"
system for applications is neat.  It grabs the unmodified tarball off
the download site, and uses a metadata file to control compile options.
Think of it as an automated linux-from-scratch.

  Remember that I mentioned that I deleted the "sendmail" symlink to
avoid embarressing incidents?  Well, it turns out that both gnupg and
slrn will *NOT* build if they can't find an executable named
"/usr/sbin/sendmail" (slrn does offer the choice of using a *DIFFERENT*
MTA as a ./configure option, but does *NOT* offer the choice of *NO*
MTA).  These stupidities are not the CRUX port-maintainer's fault.
They're hard-coded right into the the configure or make files in the
tarballs.  I find this exceedingly dumb.  Interestingly, mutt is much
nicer in this area.  It allows you to set the MTA in the muttrc, rather
than hard-coding it into the executable like slrn or gnupg.  And it'll
function perfectly as a mail-reader with the MTA-pointer commented out.

  Since I read mailing lists and usenet news, I occasionally slip and hit
"r" in news.  Disabling slrn from sending email is a safety feature for
me.  And I really don't understand where the gnupg maintainer gets off
requiring the presence of "/usr/sbin/sendmail".  Unless I'm missing
something, my MUA is supposed to call gnupg to sign and/or encrypt
email, after which my MUA sends the email to an MTA; or is gnupg
supposed to be able to send out email on its own?  Anyhow, since the
idiots insist, I've stuck in /usr/sbin/sendmail and made it executable,
like so...

#!/bin/bash

# This file is dedicated to those ####wit programmers who set up config
# files such that their programs will not even attempt to build or
# install if they can't find an executable named "/usr/sbin/sendmail"

exit


-- 
Walter Dnes <waltdnes-SLHPyeZ9y/tg9hUCZPvPmw at public.gmane.org>
Email users are divided into two classes;
1) Those who have effective spam-blocking
2) Those who wish they did
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml