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)
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
