On Thu, Sep 25, 2008 at 06:10:39PM -0500, Matthew Woehlke wrote: > >> 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. Not suddenly. Between releases and marked in release notes. >> cron now requires /usr/sbin/sendmail, which is enough in my opinion. > > Well then... say so :-). Yesterday would have been a nice time :-). I said it much before when I listed what dependend on what and what provided what. But it is not what you want. You want to have local delivery working in the default case. In order to achieve your goal: 1) we could add a new virtual provides, like Requires: mail(local-delivery) meaning that the software directly or indirectly provides /usr/sbin/sendmail and is configured to do local delivery in the default case. exim, postfix and sendmail could then provide that, and even a package installing /etc/esmtp.conf with local mail delivered through procmail condfigured, depending on procmail and esmtp. 2) we could say that the MTA virtual provides means provides /usr/sbin/sendmail, server(smtp), aliases, and the same than mail(local-delivery), and have cron depend on MTA. exim, postfix or sendmail would then be selected 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. 4) to select the default program that provides /usr/sbin/sendmail we could make sure that it is a program that provides mail(local-delivery). I think that all those are wrong. In my opinion 4) should be considered when choosing the default programs, but should only be one of the element to consider when selecting the default application. > Well, I feel it's a regression for people relying on the previous > default; especially if they don't realize anything has changed. They should read release notes. > 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. 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. > Well, obviously I disagree that there is anything wrong with the current > local mail behavior for non-root. It is not wrong, but it is arbitrary. I think that local mail delivery should not be granted. If the package that that provides /usr/sbin/sendmail delivers mail locally, then fine, if it doesn't, then fine too. And, still in my opinion, the upsteram conf should be followed. > 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. Maybe what should be done for F10 could be to choose a /usr/sbin/sendmail provider that is a full blown MTA, and discuss what functionnalities should the default package providing /usr/sbin/sendmail have. But it would certainly lead to the same debate. >> 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". 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. -- Pat -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
