(After Christoph's contribution, I feel like this is too long of a
reply. Sorry :-). I'm still trying to understand what the future plans
are, hence some of the longer paragraphs...)
Patrice Dumas wrote:
On Thu, Sep 25, 2008 at 04:04:41PM -0500, Matthew Woehlke wrote:
...you still need to let them know there is something they need to do,
that they never had to do before (which in itself has Irate User
potential).
Those who read those mails are not regular users. They are power users.
They should control their setups.
The default configuration works fine for me.
It is fedora here, not Red Hat. I am in no way affiliated with Red Hat.
(See my reply to Seth Vidal.)
And I am not playing game with people data,
If local mail suddenly went to /dev/null, and I didn't realize that, you
/would/ be playing with my data.
if you really care
about root mail being delivered locally you should willingly enable it,
and shouldn't rely on the default configuration of some application
(on a clean install).
Why do people keep assuming I am talking about root's mail. Where did I
say that?
(Even if I was, maybe I regularly become root just to check root's mail...)
Or make cron require an MTA. Or possibly both.
cron now requires /usr/sbin/sendmail, which is enough in my opinion.
Well then... say so :-). Yesterday would have been a nice time :-).
The problem is that the distribution settled to a specific default
that is not generic and effective only in some cases. I think that no
default would be better.
Well, I feel it's a regression for people relying on the previous
default; especially if they don't realize anything has changed.
Point of clarification: would installing cron restore the old behavior?
(That is, working local mail delivery...) If so, well, it will be hard
to set up cron-based backups when cron isn't installed, so effectively
'yum install cronie' will get things working the way they always did.
I do understand that you want backward compatibility for a feature that
you find important. I think there is nothing wrong with that, and
indeed, breaking past stuff is bad. However, breaking backward
compatibility is also needed when something was done wrong and badly
designed and yet made its way in the distro. Having a MTA like sendmail
installed in the default case and started as a daemon was wrong.
Well, obviously I disagree that there is anything wrong with the current
local mail behavior for non-root.
Anyway... the point is that I don't consider it acceptable to break
backward compatibility in a way that may a: go unnoticed, and b: have
disastrous consequences. Making cron require a reliable* MTA avoids the
disastrous consequences. An anaconda/firstboot screen would fix the
"unnoticed" bit. Either is acceptable (both would be preferred, of course).
The whole point has been, don't break things until the mechanism to
handle the fallout is in place. Sounds like we've decided to do that.
Now... was that so hard? :-)
(* where "reliable" means that cron's mail will wind up either in the
local spool like always, or will safely arrive somewhere that a user
used to local mail will notice it, with a failure rate at or below what
we have now)
(I happen to disagree, but that's me... Unless you're only talking about
the daemon(smtp) part, and not the MTA part that handles local mail.)
I am mostly talking about the server(smtp) part. But also about local
delivery. At least something lighter should be used (maybe a wrapper
script around procmail?).
Hehe, given the 1.9 M girth of sendmail, I can agree with that :-), but...
But a random app that provides
/usr/sbin/sendmail would also be right, even if it doesn't do local
delivery.
...not this, unless said MTA is reasonably assured to deliver cron's
mail, as per my definition (above) of "reliable".
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"You know what Microsoft's problem really is? They've lost the ability
to feel ashamed." -- Pamela Jones (Groklaw)
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
