While responding to ticket 4788: On Fri, Feb 10, 2006 at 09:12:10PM +0100, [EMAIL PROTECTED] wrote: > > Why not use versioned local_state_dir? Wouldn't doing this upon initial > > production launch of this capability in 3.1.1 minimize future migration > > issues > > and keep things inform? > > The main issue is that in 3.2 (and with the patch in this ticket), > local_state_dir overrides def_rules_dir, > which won't work with the way 3.1 currently does things > (come to think of it, it may not work in 3.2 either... have to investigate.)
So here's what I was thinking in the "come to think of it" line: If we're going to distribute code-related rules in the standard distribution (rules directory, gets installed to /usr/share/spamassassin), and then the rest of the rules go via sa-update into the local_state_dir area ... SpamAssassin will see local_state_dir, and use it for all rules, bypassing the def_rules_dir (/usr/share/spamassassin). So won't all the code-related rules be ignored? (warning: this is from just reading the code, not actually testing the code...) ie: The old way of reading in rules: default_rules_path (/usr/share/spamassassin) site_rules_path (/etc/mail/spamassassin) default_userprefs_path (~/.spamassassin/user_prefs) is now replaced by: default_rules_path (/var/lib/spamassassin/<version>) site_rules_path (/etc/mail/spamassassin) default_userprefs_path (~/.spamassassin/user_prefs) What I'd rather see is: default_rules_path (/usr/share/spamassassin) updates_rules_path (/var/lib/spamassassin/<version>) site_rules_path (/etc/mail/spamassassin) default_userprefs_path (~/.spamassassin/user_prefs) Thoughts, comments? -- Randomly Generated Tagline: "One should admire Windows users. It takes a great deal of courage to trust Windows with your data." - Unknown
pgp1Sjq0tXRn7.pgp
Description: PGP signature
