http://bugzilla.spamassassin.org/show_bug.cgi?id=3497
------- Additional Comments From [EMAIL PROTECTED] 2004-06-09 18:21 ------- Subject: Re: New: -a should not cause service failure On Wed, Jun 09, 2004 at 04:46:34PM -0700, [EMAIL PROTECTED] wrote: > A recent change to SVN trunk changed -a and --auto-whitelist options from > "ignore" to fail. This causes many upgrade scenarios to fail service startup > for no easily visible reason. RH is concerned about this, and would suggest > that -a go back to "ignore". Don't take this the wrong way, but I find this extremely humorous. I've had to spend many many hours manually getting my RH machines updated recently because RH (at least the EL side) officially doesn't support upgrades between different major versions of their OS. RH9 to EL? Nope (ok, RH9 isn't EL, but it's trivial to do guys). AS2.1 to AS3? Nope. "We don't support upgrading." ... a big thanks out the RH people who argued this point with me last week on my sev 1 ticket at 1am... <grumble> It's also humorous because RH's 2.55 RPM obsoletes our RPMs: Name-Version-Release obsoleted by Name-Version-Release ------------------------------------------------------------------------------- perl-Mail-SpamAssassin-3.0.0-svn20963 spamassassin-2.55-3.1 Oh, you have 3.0.0 installed? Well, clearly you need to upgrade to 2.55! One word: lame. > "The auto-whitelist option is obsolete and must be removed from the server > configuration file. Please notify your system administrator." > > Something like this is possible? Ok, so enough of me sharing my feelings about RH. (sorry, needed to vent, they've really pissed me off recently). As for -a ... Yes, it will break some people's install. From my POV that's not a bad thing. I have three things here. 1) 2.x to 3.0 is a major upgrade, and people need to read the docs and test to make sure things work after the upgrade. 2) We should generally "do the right thing" in the face of people not reading the docs, because let's face it -- it'll happen a lot. 3) Obsolete options need to be removed at some point. We typically keep obsolete options around for one minor version (2.5x -> 2.6x) update, but remove it from that point on. IMO, 2.x -> 3.x is major enough that the options can just be removed. So here's my thoughts: I'm opposed to ignoring the now obsolete options. Silent failures are damn annoying, and I don't want to add an FAQ about "Why doesn't autowhitelist work in 3.0?" I'm also opposed to making now obsolete options throw a warning. A lot of people are going to miss the message, either by not paying attention, or it'll go into syslog and never be seen again, or ... I would be ok with throwing an error on the now obsolete options. As an admin, after an upgrade, I'd rather have an application not start and having it force me to look at what it outputs/the log/etc. I've had numerous times where I'll do an upgrade, the application will start, and I think it'll be fine. Then the next day, a bunch of people will complain because it doesn't work right. It'd be much better for the application to go "uh-uh, you're doing something wrong, go fix it now," and even nicer if it pointed in the right direction ala "The '-a' option has been deprecated. Please read the 'use_auto_whitelist' section of the Mail::SpamAssassin::Conf man page." > Perhaps also a warning can be added to logs and/or > the headers or body of spam mail? Ewwww! Logs I can see, headers definitely not. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
