Re: Mutt dependency on an MTA
On Sat, 31 Jul 1999, Hamish Moffatt wrote:
> On Fri, Jul 30, 1999 at 10:22:07AM -0600, John Galt wrote:
> > to check my POPmail until I rebuilt the system :( ). As for a MUA that
> > doesn't require a MTA not being a useful solution for many users, look at
> > the popularity of fetchmail, a MTA that is mostly for grabbing POP mail:
>
> I wouldn't classify fetchmail as an MTA; it doesn't do any of the same
> things. Besides, fetchmail needs a local MTA to actually deliver the mail
> it has retrieved. It's more like a mail retrieval agent (MRA, if there was
> such a term).
Yeah, but Fetchmail doesn't require (or even recommend) a MTA, so why
should a MUA? I would think that Fetchmail would need a MTA more to
"...provide a significant amount of functionality" than a good portion of
MUAs.
>
> > wouldn't it be a more elegant solution to simply remove all MTAs from the
> > system and use a MUA that has POP/IMAP retrieval capabilities in that
> > particular case? Installing something for a portion of it's usefulness is
> > NEVER an elegant solution, in fact, I'd call it a kludge offhand. There
> > ARE MUAs that need no local MTA to do the job they're installed for, so
> > why force users into installing a package that might never see use at
> > all--sounds like the MUA really didn't depend on the MTA at all, doesn't
>
> I think you are making a mountain out of a molehill. For most users,
> those MUAs depend on an MTA. For a few users, it may not be required.
>
> How do you suggest we handle that? If you make eg mutt only recommend
> mail-transport-agent, then dselect users get it anyway (since dselect
> makes recommends almost as strong as depends), and apt-get users (who
> in most cases do want an MTA) won't get it. So absolutely nobody benefits.
Who benefits now? A MTA that requires, ohhhh say PERL for example, could
actually nuke the entire mailing system on an upgrade, removing both the
MTA and the MUA, despite the fact that the MUA is perfectly usable (not
having any perlscripts). As far as an apt user not getting the MTA because
it isn't required and breaking the mail system: if it's that bad, make a
MTA as priority:required --it's more logical than breaking the definition
of Depends: for a small class of packages.
> What's the harm in having an MTA installed even if you don't use it? It
> doesn't interfere. Actually, a few system tasks depend on having an MTA;
> cron will email you the text output (if any) of your cron jobs, for
> example. I think a unix system without an MTA would be broken.
See my original reply--it's a kludge. Installing a useless package just
for compatibility kind of ruins the flexibility native in a Unix, no?
Cron recommends a MTA, so why should a MUA that uses the MTA in
the same manner that cron does be different?
Secondly, if you think that a MTA-less system is broken, IIWY I'd angle
for a priority:required instead of a Depends: on an Extra package.
> > lie. I never used mutt much, so can't say for sure if it can use a remote
> > host's MTA and POP/IMAP, but if it can, then it can function without a
> > MTA, so the dependency should therefore be reclassified.
>
> It can do POP, but doesn't (TTBOMK) support delivery except via the local MTA.
I stand corrected on the particular case: mutt may very well NEED a MTA,
but I won't say that for all MUAs: pine and elm both can do without a MTA
and do a perfectly good job, provided you use them only for POP/IMAP from
a SMTP server--sounds like Recommends: "...list packages that would
normally be found together with this one in all but unusual installations"
BTW, my quotes are from DPM, section 8.2
>
> Hamish
> --
> Hamish Moffatt VK3SB (ex-VK3TYD).
> CCs of replies from mailing lists are welcome.
>
Artificial intelligence is no match for natural stupidity.
Who is John Galt? galt@inconnu.isu.edu, that's who!
Reply to: