Patrice Dumas wrote:
On Thu, Sep 25, 2008 at 03:11:52PM -0500, Matthew Woehlke wrote:
Besides; Patrice, your argument is that we should remove functionality
that is critical to some users because no one has bothered to fix the
/bug/ that by default logwatch sits around filling the spool with large,
mostly-redundant messages.
It is not really my argument. First I think that these issues are
power user issues.
Yes, but...
And then that there is no clear solution for this
issue, there are many use cases with different choices. So, if there no
integrated solution, like something with firstboot, /etc/sysconfig or
whatever the users should not rely on a specific setup and should setup
what they prefer and configure it themselves. And they can do that since
they are power users. Starting from this point of view it is better to
have nothing started nor configured and things only pulled in as
dependencies.
...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).
And I strongly disagree with changing from 'something that always worked
before' to 'nothing, with potentially catastrophic consequences if you
don't know that we removed functionality' being a good idea.
I don't really care that it worked before,
Obviously, I do :-). You're "removing" a feature I depend on. It would
be one thing if you have a way to ensure that I know this has been done
so that I can re-enable it. You apparently feel differently.
once again it is a very specific
use case and I can't see why it should be priviledged.
...because so far I haven't heard that you've ensured people depending
on this will know they have to do something special, now. And, as I've
pointed out, that lack of knowledge can have severe consequences.
Because - ok, I told myself I wouldn't, but I'm going to pull out the
Big Gun now - if Red Hat did this, and I lost data because of it, I'd be
filing a lawsuit. Seriously. You're talking about playing games with
people's data, and I don't take that lightly.
And I don't understand why we're still having this conversation. Several
suggestions (that, to me at least, seem perfectly reasonable) have
already been suggested. Something in anaconda or firstboot would be best
(ideally, you could configure things like if you want logwatch at all),
that would make sure you either get a local mail MTA, or are required to
click through the Big Scary Warning about the Dire Consequences if you
elect not to run one. Or make cron require an MTA. Or possibly both.
I'm willing to blame it on user negligence if they knowingly choose not
to have an MTA, or purposefully circumvent cron's normal use thereof. I
*don't* consider it acceptable for the default cron setup to be changed
from one that (IMO) is effective, to one that silently discards output
in a way that the user may not even be aware that there is a problem.
Why is that so hard to understand?
(And I'll repeat what I said elsewhere. The replies I'm getting from
some people seem to indicate that this is a real issue. If I'm really
just inventing a scenario that can't happen, /someone bloody please just
tell me!/)
I think that it
was always a mistake to start sendmail in the default case, and even to
install it (not as a dependency).
(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.)
Well it should not be changed within
a release, nor by updates, but I would find it normal to have it broken
by clean installs (with release notes, if possible).
Who reads release notes? :-)
--
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
