CRM114 version specifics?

[Steve Campbell]

Thanks all for the info.

Now, what about version specifics. Will CRM114 run with older versions 
of SA? Is it pretty generic or real specific? It's been around for a 
long time, as I read it, but wasn't used specifically with SA, so I 
wonder if it will run with my 3.0.1 SA.

Steve says thanks

Matt Kettler wrote:
> 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.
>
>
>
>
>
>
>
>