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