Re: [sa-list] Re: [sa-list] Re: Default Plugins?

["Dan Mahoney, System Admin" <da...@prime.gushi.org>]

On Sat, 4 Aug 2007, Theo Van Dinter wrote:

> On Fri, Aug 03, 2007 at 10:59:31PM -0400, Dan Mahoney, System Admin wrote:
>>>> Is there some default mechanism loading these things (for example, I
>>>> notice loadplugin Mail::SpamAssassin::Plugin::DKIM is only in v312.pre),
>>>> and is it safe to remove the old ones?
>>
>> So then, what if, for example, nothing else had loaded
>> Mail::SpamAssassin::Plugin::DKIM?
>
> If nothing loads that plugin, then you don't get the functionality.  SA reads
> *.pre, so as long as a plugin is loaded in one of them, it's loaded.
>
>> It wasn't in the other files, even in a commented out format?
>>
>> Should there be a "Lint" of all the possible modules (and worst-case
>> scenario, I get an error if I try to load a module twice)
>
> You can't list all the possible modules, since they can live anywhere.  You
> could get a list of the standard/default modules, and any modules that an
> update channel gives you though.

No, but YOU (the SA team) can, in fact, list all of the modules that you 
are shipping with a specific version of SA, in a commented (and possibly 
commented out) version of $version.pre.

Notes in there such as:

'"Mail::SpamAssassin::Plugin::DomainKeys" is officialy outdated by "Mail::SpamAssassin::Plugin::DKIM"'

would be nice things too (as presumably, nothing is going to ever REMOVE 
that old module from its installed location for those of us using the 
make, make install method, and because SA will still read the 
three-versions-ago command to LOAD that module.

> However, I don't know what a lint would do for you.  Plugins are optional (*),
> so not loading them isn't a reportable problem.  In fact, that's one of the
> main benefits of having plugins: being able to not load certain functionality,
> reducing the amount of resources needed to run SA, etc.

Maybe I didn't mean the same thing by LINT you thought I meant?  Under 
BSD, there's a kernel config file called LINT that lists every possible 
kernel config option (even cross-incompatible ones) so you can at least 
see and grep for them all.  In older versions, this was fully commented. 
In more recent versions, it's programmatically generated, which means 
there's no nice human readable comments, but that it's more likely to be 
all-inclusive.

In the case of SA, the printing of such a message/description could come 
from the self-contained POD documentation.

While I feel it's my duty as an admin to know which modules I installed 
myself, and which were "stock" (pretty simple, based on which config file 
loads them from where, in most cases), it's only stated in the included 
docs that NEW modules are in $version.pre (which doesn't help AT ALL if I 
missed a version bump, or am installing clean).

Even now, there could be functionality I'm missing, simply because I 
haven't installed every minor version in between.

-Dan

--

"If you aren't going to try something, then we might as well just be
friends."

"We can't have that now, can we?"

-SK & Dan Mahoney,  December 9, 1998

--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---------------------------

Re: [sa-list] Re: [sa-list] Re: Default Plugins?

[Theo Van Dinter <fe...@apache.org>]

On Sat, Aug 04, 2007 at 07:55:06AM -0400, Dan Mahoney, System Admin wrote:
> No, but YOU (the SA team) can, in fact, list all of the modules that you 
> are shipping with a specific version of SA, in a commented (and possibly 
> commented out) version of $version.pre.

Sure, and that's exactly what we already do.  It's just that $version is the
version the plugin was first introduced.

> would be nice things too (as presumably, nothing is going to ever REMOVE 
> that old module from its installed location for those of us using the 
> make, make install method, and because SA will still read the 
> three-versions-ago command to LOAD that module.

Yeah, it's hard to remove the old plugins, though we could overwrite them with
a new version that has all the code ripped out.  It could even raise a flag
saying that the plugin is deprecated.

> Even now, there could be functionality I'm missing, simply because I 
> haven't installed every minor version in between.

If you were to upgrade from say 3.0.3 to 3.2.0, the install process will
install all of the v31x.pre files, and the plugins in 3.2.0 are inclusive of
all the ones from 3.1.x.   So you're not missing anything if you didn't
install all the ones in between.

-- 
Randomly Selected Tagline:
"When we traded it in my wife was upset because we didn't keep it long
 enough for her to buy a gun and shoot it."
         - Unknown about the Cadillac Cimarron

Re: [sa-list] Re: [sa-list] Re: Default Plugins?

["Daryl C. W. O'Shea" <sp...@dostech.ca>]

Dan Mahoney, System Admin wrote:

> Even now, there could be functionality I'm missing, simply because I 
> haven't installed every minor version in between.

No, that's not correct.  Every version includes all of the pre files and 
plugins from every version before it.  If the pre files aren't present 
on your system they will be installed.  All of the plugins will be 
installed no matter what (your existing M::SA Perl lib directory is 
cleaned out during make install).

Daryl

Re: [sa-list] [sa-list] Default Plugins?

[Kai Schaetzl <ma...@conactive.com>]

System Admin Dan Mahoney wrote on Sat, 4 Aug 2007 07:55:06 -0400 (EDT):

> '"Mail::SpamAssassin::Plugin::DomainKeys" is officialy outdated by 
"Mail::SpamAssassin::Plugin::DKIM"'
> 
> would be nice things too (as presumably, nothing is going to ever REMOVE 
> that old module from its installed location for those of us using the 
> make, make install method,

As Jason says this is all told in the INSTALL file, quite clear and in some detail. 
And, if you upgraded with make as you said you will also notice that the output of 
"perl makefile.PL" will remind you about it.

The usage of *.pre files is also explained, in the README.

It's all there. I'm just upgrading to 3.2.2 and I'm finding it very easy if I take the 
minimal amount of time to at least rush thru these files. Actually, the hint in the 
configure step is already enough to tipp you off.

Kai

-- 
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com

Re: [sa-list] Re: [sa-list] Re: Default Plugins?

["Daryl C. W. O'Shea" <sp...@dostech.ca>]

Dan Mahoney, System Admin wrote:

> Even now, there could be functionality I'm missing, simply because I 
> haven't installed every minor version in between.

No, that's not correct.  Every version includes all of the pre files and 
plugins from every version before it.  If they're not present on your 
system they will be installed.

Daryl