-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Theo Van Dinter writes:
> 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...)

No -- because all the code-related rules are distributed in the sa-update
tarball as well.

The sa-update backend basically does "make install", and tars up the
entire contents of (what would be) /usr/share/spamassassin .

It does mean that the sa-update channels have to be versioned according to
the downloading code's version (e.g. 0.2.3.updates.spamassassin.org), but
that's part of the design anyway.

in other words: not a problem ;)   

> 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)

To clarify: it's more like

  default_rules_path    (/var/lib/spamassassin/<version> OR
                      /usr/share/spamassassin if that does not exist)
  site_rules_path               (/etc/mail/spamassassin)
  default_userprefs_path        (~/.spamassassin/user_prefs)

Loren, note the semantics of the default_rules_path ;)

- --j.


> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFD7QJfMJF5cimLx9ARAiktAJ4nlrCXaKUgMWH3SsevSjtHgj0D4wCfd0kq
LTvJtevAMOGWMsvI23HhBt8=
=pU2V
-----END PGP SIGNATURE-----

Reply via email to