http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5751
------- Additional Comments From [EMAIL PROTECTED] 2007-12-28 17:51 ------- (In reply to comment #14) > Yes but I think there is another equally valid point here which is that a > failed > (partial) update shouldn't leave you in a worse state. The first priority with > failed updates should be "DO NO HARM" And that's what sa-update already does. The issue here is that when running sa-update for a channel *the first time* when using multiple channels, people have to pay attention to whether there was a failure and if so, fix the issue and try again. I believe all other situations are handled automatically, because they can be. > I think a better answer would be to have the default case of a partial update > failure be that NONE of the updates occur unless you use a (new) command line > flag --force. If someone runs sa-update w/ different channels (for example so that updates occur at different frequencies for different channels), then you have the same problem and no commandline option or sa-update logic will be able to solve the problem. > I think this "default do-no-harm" policy is much better than just adding more > warnings. In my specific case, the sa-update was run from a root-only readable > cron file that I didn't even realize was there (we can't all know everything > about our systems :) and its ouput was buried deep in some log file so I never > even knew a failed update occurred. That's a system administration problem. > I'm not sure why anyone would object to this compromise solution since experts > like yourself could still proceed at their own risk and allow partial updates > to > occur while less sophisticated users would at worse have a still working but > not > updated spamassassin installation. IMO, bug 5193 (making sa-update more "atomic") would allow more for "fail a whole run if any part fails", if people want to go that way. I'm not opposed to that kind of change if people feel it's the better way to go. It does solve this specific situation, though not all possible similar situations, which I believe as previously described is dependent on the user. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
