http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4952
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #3550 is|0 |1
obsolete| |
------- Additional Comments From [EMAIL PROTECTED] 2006-08-03 17:51 -------
Created an attachment (id=3624)
--> (http://issues.apache.org/SpamAssassin/attachment.cgi?id=3624&action=view)
first suggested patch
Ok, here's a first version. I'm hoping for some comments before I commit it to
3.2 and let it get officially reviewed for 3.1.
There are four things addressed here:
1) the local state dir was an API addition made in 3.1.1 due to the change to
how sa-update was expected to function. however, no default was set such that
third party tools had to keep up with the API change. I added in defaults for
DEF_RULES_DIR, LOCAL_RULES_DIR, and LOCAL_STATE_DIR into M::SA::new() that get
replaced at "make" time. This way, even if the caller doesn't pass them in,
the defaults will be usable.
2) There was no documentation for the path variables passed into M::SA::new(),
specifically PREFIX, DEF_RULES_DIR, LOCAL_RULES_DIR, and LOCAL_STATE_DIR. I
added some, though somewhat terse.
3) There was no documented way to pass in a different local state dir ala
rules_filename, site_rules_filename, etc. After looking at the code and seeing
no way to change the default rules directory other than changing the passed in
DEF_RULES_DIR, I decided to not add a new option local_state_directory and did
#2 instead, documenting LOCAL_STATE_DIR.
4) Even if someone figured out #3 (passing in LOCAL_STATE_DIR), SpamAssassin
would not use that specific directory for updates, instead looking at
local_state_dir/spamassassin/version instead. I added in the local state
directory itself in between the previous directory and def_rules_dir.
I did not want to add another option to "spamassassin", "spamd", etc, for
"updatedir" or "local_state_dir". Which means that from the commandline
there's no easy way to override where SA looks for these files. I think the
alternate method of adding "include /alternate/path/update.cf" to the
appropriate config solves this issue, though I could be convinced that another
commandline option is the way to go instead.
thoughts, comments, rotten vegetables?
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
