Re: need to add a new class of rules source

[Justin Mason <jm...@jmason.org>]

"Loren Wilton" writes:
>> let me know what you all think.
>
>I had a little trouble following this message.  Part of the problem is I'm
>not positive I know what you mean by "compiled rules".  (Or I'm positive I
>don't know, your choice.  :-)

OK, so here's what I've done so far.

Rules files are now "compiled".  This allows us to

- put possibly-broken rules-in-development in the "rulesrc" source
  directory, without causing damage to the main ruleset if they are broken

- split rules across multiple directories, to allow the "sandbox" idea

- keep rule source in the same place, even as the rule is promoted,
  demoted, etc.

In actual fact, "compilation" is really just a script that copies the
lines from the source file into a destination file in the "rules" output
directory, so it's pretty simple.

>I also have a question on the "code tied" rules.  Which part of these rules
>are these?  You mention evals.  I would assume that the actual eval code for
>release N.M is still in the SA code base, so these would just be the the
>rules that call the eval functions?

Yep, that's the basic issue.  

http://wiki.apache.org/spamassassin/RulesProjPromotion lists the rulesets
that were split, and to where -- pretty much all the current set of eval
rules are "code-tied" and have to stay with the code.

>It seems to me there is the interesting point that some of these rules might
>be common across a few releases and others might be specific to a release.
>I'm not quite sure how you handle that case.  Maybe rules/evals/3.0,
>rules/evals/3.10, etc?

we can't really do that, since they might change *between* releases as
well -- and if we went down that route, we'd have so many
rules/evals/3.0_20050918 etc. directories that we'd eventually wind up
reinventing SVN ;)   The easier option is to keep those "code-tied"
rules as part of the source distribution.

>It definitely seems to me that you don't want the test rules to be landing
>in the same directory with existing rules.  But I didn't follow quite well
>enough to suggest something, other than I'd rather use more directories and
>keep the CF suffix.

I actually don't mind the test rules landing in the same dir as the
compiled existing rules, but just not in the same dir as the *source*
for the existing rules.  Thanks for the vote on the "use more directories"
idea though ;)

--j.

Re: need to add a new class of rules source

[OpenMacNews <Op...@speakeasy.net>]

hi justin,

   re: "Re: need to add a new class of rules source" @
   http://www.mail-archive.com/dev@spamassassin.apache.org/msg10993.html,

i'm in the process of bldg a bleeding edge instance of exim/clam/cyrusimap w/ SA-dev (svn 
r312807) on OSX 10.4.2 for testing ...

i've noted your rules changes, and found (some of) them in rulesrc.

on exec-ing:

perl Makefile.PL \
PREFIX=/usr/local/spamassassin \
DATADIR=/var/MailServer/Conf/SA/Dist \
CONFDIR=/var/MailServer/Conf/SA/Local \
ENABLE_SSL="yes" \
LDDLFLAGS="-L/usr/local/ssl/lib -lssl -lcrypto" \
LDFLAGS="-bind_at_load -L/usr/local/ssl/lib -lssl -lcrypto -ldl" \
INC="-I/usr/local/ssl/include"

i get a failure of:

   Checking if your kit is complete...
   Warning: the following files are missing in your kit:
         rules/20_advance_fee.cf
         rules/20_body_tests.cf
         rules/20_compensate.cf
         rules/20_drugs.cf
         rules/20_fake_helo_tests.cf
         rules/20_head_tests.cf
         rules/20_meta_tests.cf
         rules/20_phrases.cf
         rules/20_porn.cf
         rules/20_ratware.cf
         rules/20_uri_tests.cf
         rules/25_body_tests_es.cf
         rules/25_body_tests_pl.cf
         rules/25_replace.cf
         rules/30_text_de.cf
         rules/30_text_fr.cf
         rules/30_text_nl.cf
         rules/30_text_pl.cf
         rules/30_text_pt_br.cf
         rules/50_scores.cf
         rules/60_whitelist_spf.cf
   Please inform the author.

which are in rulesrc/... and, simply seems like the MANIFEST is out of sync ...

is it in flux and will be managed later, and we should just manually workaround?

or is it something that can/should be changed at this point?

thx! & cheers,

richard
-- 

/"\
\ /  ASCII Ribbon Campaign
  X   against HTML email, vCards
/ \  & micro$oft attachments

[GPG] OpenMacNews
fingerprint: 3F07 3CFD 138A FD91 A4A6  1840 1A7A 8CCB 882F 67A1