http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5751
------- Additional Comments From [EMAIL PROTECTED] 2007-12-20 22:52 ------- Well, I think part of the problem in my case (and in the likely use case) is when someone has default rules installed in __def_rules_dir__ (in my case /usr/share/spamassassin) but then gets only a partial update installed in __local_state_dir__/spamassassin/__version__ (/var/lib/spamassassin/3.002003 in my case). In fact, even if just the directory __version__ (3.002003) is created then, suddenly all the rules in __def_rules_dir__ are overriden. This would occur even if no rules are added to the directory (or in my case the rules that were in 3.002003 all had errors because they were missing dependencies), resulting in effectively NO RULE CHECKING. Wouldn't a more forgiving approach be to first look in __version__ and then continue to look in __def_rules_dir__ if the subdirectory updates_spamassassin_org is not present. Then, additionally, in order to prevent incomplete updates, the repository subdirectories would not be added (or later changed) in __version__ if the repository update is not successful. This would ensure that __def_rules_dir would never be overriden unless a successful update occurred to updates_spamassassin_org (or more generally the user-defined default repository). To preserve separation of rules and engines, one could make a user-defined variable assign which repository is the primary rule set for updates. The default value of that variable would likely be updates_spamassassin_org So, in my case, the failure of updates_spamassassin_org to update would leave that directory missing from __version__ (as it was) so that spamassassin would continue to look also at __def_rules_dir__ for the base rule set. If you truly want to ignore all rules in __def_rules_dir__ then you could create an empty directory updates_spamassassin_org (or whatever your default repository is) so that spamassassin would think that the ruleset was updated successfully. There are many possible variations on the above ideas but I would think that it would be more robust than the current approach. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
