CRM114 version specifics?

[Matt Kettler]

Glenn Steen wrote:
> On 31/07/07, Alex Broens <ms-list at alexb.ch> wrote:
>> On 7/31/2007 2:41 PM, Steve Campbell wrote:
>>> The turtle Steve, who seems to always be behind in updates, here.
>>>
>>> Is all of this CRM114 stuff version specific or will it run under
>>> recent/any versions of SA?
>>>
>>> Now for a little soapboxing:
>>>
>>> I see a small problem brewing with these init.pre, v300.pre, v310.pre,
>>> etc files where people are told to add things to this specific one, or
>>> that specific one, when some of these don't exist and for the most part,
>>> it doesn't matter which one you append to. I don't have v320.pre because
>>> I haven't installed it yet. Might it not be a better idea to suggest
>>> people add things to the latest *.pre they have? Should there be an
>>> update_pre script somewhere that moves things from a current .pre to the
>>> new .pre when installing upgrades? I don't think it really matters as SA
>>> will just report duplicates or something, but there could come a time
>>> when it does matter.
>> To be safe, always use your own files for your custom stuff so the
>> logical step would be to add your custom plugins load commands to
>> something like a "myplugins.pre" file.
>>
>> A SA setup/update won't touch that file and you can stop worrying.
>>
> Actually, the "plethora" of .pre files is to facilitate safe upgrades
> (and downgrades)... Each is meant to only hold stuff that is specific
> the version where it is introduced (and later versions, of course)...
> At least assuming IUC;-). Matt K will slap us silly if we get it
> wrong:-D.
> But having your own for that too is safe and probably even a good idea.

I agree.. when adding on my own plugins, I create a separate .pre file,

OR, sometimes, I include the loadplugin in the .cf file for the plugin. Many
add-on plugins do this by default, and it is safe as long as the plugin isn't
referenced by any rules that might be parsed before the loadplugin command. This
is true for all add-on plugins, unless it is trying to replace one of the ones
that comes with SA (a "standard" plugin, and I know of none that do this at present)

The primary reason the standard plugins that come with SA are in .pre files is
that /etc/mail/spamassassin/*.pre gets loaded before the default rules (ie:
/usr/share/spamassassin/* or
/var/lib/spamassassin/<version>/updates_spamassassin_org.cf).

Rules in the default set actually check for the various standard plugins, but
that only works if the plugin is loaded first. (otherwise the check fails and
the rules get skipped). Thus, the .pre files are needed so the plugins get
loaded first.

However, an add-on plugin won't be referenced by the standard rules, only the
ones that come with the plugin.

In general As long as the loadplugin occurs before any of the rules that use it,
you're fine.