http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5171
------- Additional Comments From [EMAIL PROTECTED] 2006-11-09 10:21 ------- > meta rules won't throw an error, but score and description lines will. well, sure, it's not a *fatal* error. but still, this: [30726] info: rules: meta test FORGED_OUTLOOK_TAGS has undefined dependency '__MIME_HTML' [30726] info: rules: meta test FORGED_OUTLOOK_TAGS has undefined dependency '__TAG_EXISTS_HTML' [30726] info: rules: meta test FORGED_OUTLOOK_TAGS has undefined dependency '__TAG_EXISTS_HEAD' [30726] info: rules: meta test FORGED_OUTLOOK_TAGS has undefined dependency '__TAG_EXISTS_META' [30726] info: rules: meta test FORGED_OUTLOOK_TAGS has undefined dependency '__TAG_EXISTS_BODY' is pretty ugly, and I'd still consider it some class of an error ;) The only workaround I could see would be to "ifplugin Mail::SpamAssassin::Plugin::HTMLEval" every single meta rule that used one of those rules; then ifplugin their score lines and descriptions; then ifplugin meta rules using them in turn etc. etc. > Then essentially what you want is all the rule plugins to be standardly loaded > modules again which is what we've been trying to get away from... The general > rule for using plugins is that all related configs *have* to be in an ifplugin > conditional. Even if you load all the pre files, the user can comment out > plugins, so you'll be back to where you started. Sure. But there's a limit to how deep it can go. I think it's fine to "ifplugin" stuff like DKIM, DCC, Hashcash etc -- there are small, independent rulesets there. In fact, in my opinion Bayes would be an arguably good addition, too. But the rules moved from EvalTests.pm -- they're still core in a way. I know I argued that they *should* be made into plugins -- I agree it was a good idea. However, my use-case scenario I argued this from, was for somebody who's using SpamAssassin with their own, entirely built-from-scratch ruleset; ie. someone who didn't want to use any of SpamAssassin's builtin rules. (I know of quite a few groups doing this for various reasons.) In other words I don't think it is a good idea to go from saying "they should be plugins" to making rules like "and since any plugin can be safely disabled without error, any lines referring to them require an 'ifplugin' scope". Some plugins have to be considered "core" requirements of the default ruleset. (by the way it's not just those rule plugins that this applies to -- the new Check plugin is similarly a "core" requirement.) I'd be very happy to add caveats and warnings to the comments of the .pre files noting where this is the case, btw. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
