please deactivate services by default!

[Matthew Woehlke]

Patrice Dumas wrote:
> 3) we could change the meaning of the /usr/sbin/sendmail provides, and
>  require that it is the same than mail(local-delivery). In that case 
>  ssmtp could not provide it anymore since it cannot do local delivery.

See... that bothers me. Obviously, I have an expectation of working 
local mail on my system, which apparently means /usr/sbin/sendmail 
providing that. IMO, a package that does not provide local mail should 
not provide /usr/sbin/sendmail, because it is /not/ providing equivalent 
functionality, and is therefore /not/ interchangeable.

(Ok, so obviously this is true of most alternatives, but then, I'd argue 
that non-common functionality should be available through non-common 
provides, be they files or virtual-provides. Ah, so, I guess that means 
that if /usr/bin/sendmail isn't guaranteed to do local, then yes, we 
/do/ need a virtual-provides for that.)

I guess the real problem is that certain things (cron, smartctl, 
logwatch) have an expectation of notification delivery. Historically, 
this has been provided by local mail. It sounds like you are telling me 
there is currently no package dependency to ensure this, i.e. I could, 
if I don't know what I'm doing, switch from sendmail to ssmtp and break 
cron in the process, and yum/rpm won't tell me I'm doing something bad.

> Unless I am wrong cronie is in the default package set, and so it drags
> in /usr/sbin/sendmail dependency. If there is no package in the default
> set already providing it, exim would be choosen since the shortest name
> wins. But maybe there is a package in th edefault set that provides
> /usr/sbin/sendmail.

If something providing local mail is in the default set, then where did 
comments like "if there are cron jobs that send mail, we will deactivate 
them" come from? I keep wondering if this whole thread is a result of 
people making wrong assumptions, and other people, rather than 
clarifying, throwing fuel onto the fire instead. (And yeah, I'm part of 
it, but I'm operating from ignorance; it's the people that know better 
and aren't stepping in to correct the errors that I'd be annoyed with.)

> Well, my opinion is that how reliable the /usr/sbin/sendmail is should
> be left to the user installing it, or to the default /usr/sbin/sendmail 
> provider decision and not be tight to the previous use case.

If something is added to firstboot, that's fine. Then it's on the user's 
head if they mess it up. I still feel that providers shouldn't go making 
things worse than before.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Who wants to sing?" -- Orcs (Warcraft II)