Spamassassin config files in /usr/share

2002-04-06 Thread Blars Blarson 
The spamassasin maintainer doesn't think that there are settings
in /usr/share that can't be overridden by the settings in /etc
should be considered "serious".  See bug #141125 and spamassassin 
bug #188.

Currently, I edit the file in /usr/share to implement my site-wide
policies, but this will be overridden every time spamassassin is
upgraded.

Why shouldn't this be considered a violation of policy 11.7.1?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Spamassassin config files in /usr/share

2002-04-06 Thread Anthony Towns 
On Fri, Apr 05, 2002 at 11:45:08PM -0800, Blars Blarson wrote:
> The spamassasin maintainer doesn't think that there are settings
> in /usr/share that can't be overridden by the settings in /etc
> should be considered "serious".  See bug #141125 and spamassassin 
> bug #188.

It's not a configuration file, therefore it needn't be in /etc. Obviously
it'd be better if it were a configuration file, but that's a wishlist bug.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

 ``BAM! Science triumphs again!'' 
-- http://www.angryflower.com/vegeta.gif


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Spamassassin config files in /usr/share

2002-04-06 Thread Colin Watson 
On Fri, Apr 05, 2002 at 11:45:08PM -0800, Blars Blarson wrote:
> The spamassasin maintainer doesn't think that there are settings
> in /usr/share that can't be overridden by the settings in /etc
> should be considered "serious".  See bug #141125 and spamassassin 
> bug #188.
> 
> Currently, I edit the file in /usr/share to implement my site-wide
> policies, but this will be overridden every time spamassassin is
> upgraded.
> 
> Why shouldn't this be considered a violation of policy 11.7.1?

Lots of things aren't configurable that should be. For example, you have
to recompile a lot of packages to change some of their build-time
options, which is even more work than changing a file in /usr/share. Not
every one of these is a release-critical bug.

-- 
Colin Watson  [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Spamassassin config files in /usr/share

2002-04-06 Thread Malcolm Parsons 
On Fri, Apr 05, 2002 at 11:45:08PM -0800, Blars Blarson wrote:
> Currently, I edit the file in /usr/share to implement my site-wide
> policies, but this will be overridden every time spamassassin is
> upgraded.

Why not use dpkg-divert?
 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Spamassassin config files in /usr/share

2002-04-06 Thread Sean 'Shaleh' Perry 

On 06-Apr-2002 Malcolm Parsons wrote:
> On Fri, Apr 05, 2002 at 11:45:08PM -0800, Blars Blarson wrote:
>> Currently, I edit the file in /usr/share to implement my site-wide
>> policies, but this will be overridden every time spamassassin is
>> upgraded.
> 
> Why not use dpkg-divert?
>  

that is obviously a good short term solution.  But should a user need to do this
for the long term?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Spamassassin config files in /usr/share

2002-04-06 Thread Joey Hess 
Blars Blarson wrote:
> The spamassasin maintainer doesn't think that there are settings
> in /usr/share that can't be overridden by the settings in /etc
> should be considered "serious".  See bug #141125 and spamassassin 
> bug #188.

If you really must exactly offset amazon's whitelisted score, you can
probably do it by writing a separate rule like this:

header AMAZON_OFFSET_WHITELIST From =~ /amazon/
score AMAZON_OFFSET_WHITELIST 100

-- 
see shy jo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]