Background: 

The SA team generally knows the perl modules used by SA itself and the various 
ancilliary perl bits that are part of the release.  In many or most cases the 
minimum workable version of each module is also known, as this usually appears 
somewhere in the documentation.

Problem:

Failure to have the right module versions loaded generally results in cryptic 
perl syntax errors and other non-obvious malfunctions.  These errors annoy the 
person receiving them, take up inordinate amounts of time on the SA-talk list, 
and very often can only be recognized by an SA developer for being a sign that 
module X, Y or Z is the wrong version.

A typical exchange from the SA list today will illustrate this point:

----------------------------------
another list user, david baines helped me out on this one...
its very simply that your version of getopt::long is not recent enough

get the latest from cpan and install and it works perfectly from then on

ronan

Stephan Paukner wrote:
> On Wed, December 15, 2004 9:53, Ronan said:
> 
>>>I actually never knew about this until i was having a hoke around...
>>>anyway cant get it to run..
>>>
>>>./sa-stats.pl -l /var/log/syslog -H -T 5 -u
>>>Error in option spec: "top|T:25"
>>>Error in option spec: "SCALAR(0x4c9a68)"
>>>bash-2.03$
>>>
>>>i presume this is to do with the per user count but it even flags when
>>>i run
>>>
>>>bash-2.03$ ./sa-stats.pl -l /var/log/syslog Error in option spec:
>>>"top|T:25"
>>>Error in option spec: "SCALAR(0x4c9a38)"
>>>
>>>
>>>and even
>>>
>>>bash-2.03$ ./sa-stats.pl Error in option spec: "top|T:25"
>>>Error in option spec: "SCALAR(0x4c9a20)"
>>>
>>>
>>>any hints? thanks.
-----------------------------------------

Solution:

If SA checked the versions of all of the modules the developers know that it 
needs and made simple, clear, ERROR -- MISSING MODULE or ERROR -- WRONG VERSION 
type messages when the module either wan't present or had a useless version, 
then it would be a lot simpler for users to fix their stupid configuration 
screwups at the outset.

It would be nice if such checks were part of the install.  

But they should also be present either as a separate tool that can be run 
anytime, or incorporated into spamassassin and spamd so that they get run every 
time on program startup, and make appropriate clear and obvious log results.  
In fact, the program should probably abort immediately after the version and 
presence checks if any errors are detected, rather than continuing to run and 
making cryptic and erroneous results later on.