On Sun, 30 Nov 2014, jdow wrote:
On 2014-11-30 13:13, John Hardin wrote:
On Sun, 30 Nov 2014, Reindl Harald wrote:
> 5)
> make the condition to the SA version, there are already ton's of "if
> (version
> > = 3.004000)" rules and so it needs just to depend on SA bigger than
> > 3.4.0
> instead of the perl check
>
> why that would work?
> well, older RHEL versions as you said won't upgrade SA or perl
> that setups would not use the rule, recent ones would
And anyone who is running SA prior to 3.4.0 on perl newer than 5.8.8
(where it
would run just fine) does not get the benefit of the rule, and anyone
running
3.4.0 on perl 5.8.8 (which is entirely possible) has their sa-update lint
blow
up and they don't get *any* new rules.
The assumption "newer SA = newer perl" is not really justified.
Um, er, ah, <shuffle-feet and diffidently raise a hand>
I'd like to note that I am seeing this warning with SL6.6 loaded from EL6
repository. It's version is 5.10.1. This seems to discredit the word about
perl versions greater than 5.8.8.
Again:
This problem is not related to the version of perl that is installed.
Changing the version of perl will not fix it. It's related to the ability
to add new conditional features to SA.
There is a new feature in SA trunk that allows a conditional to check a
new pseudo-variable named "perl_version", to determine the version of perl
that is installed, similar to how the "version" pseudo-variable allows
rules to check the version of SA that is installed. For example:
# avoid generating a fatal lint error in perl 5.8.8
if perl_version >= 5.010000
body NON_5_8_8_COMPATIBLE_RE /\w++/
endif
Checking perl_version in non-trunk versions of SA causes a type error
because those versions don't recognize "perl_version" as something to
replace with the perl version and instead treat it as a literal string,
which causes a type conflict because >= is a numeric operator.
Effectively, this is what's happening in older SA:
if "perl_version" >= 5.010000
body NON_5_8_8_COMPATIBLE_RE /\w++/
endif
This would not be fixed by changing the version of perl, and will be a
problem in older SA installs even after support for "perl_version" is
officially released.
Perhaps a plugin could be developed to benignly figure out the version of
perl that is loaded. That could produce a value to be used in the rule
parsing process.
The change to the parser to recognize perl_version was about as trivial as
such changes get, much more lightweight (and neater) than a plugin. And a
change to recognize a value returned by a plugin in conditionals would
probably land us in the same place we're in now - older SA emitting a
warning regarding an unrecognized capability.
There was also a suggestion about making a can() check to determine the
perl version, but as that would require code changes in the parser to
support a parameter, we're right back to where we are now: earlier SA will
generate a warning on the conditional syntax.
Example:
if can(Mail::SpamAssassin::Conf::min_perl_version(5.010000))
Nov 30 14:13:11.973 [17507] warn: config: error in if -
$self->cond_clause_can( "Mail::SpamAssassin::Conf::min_perl_version" (
5.010000 ) ) : syntax error at (eval 2557) line 1, near
""Mail::SpamAssassin::Conf::min_perl_version" ( "
Another (ugly) alternative would be to define a bunch of functions like
this for various perl versions:
if can(Mail::SpamAssassin::Conf::min_perl_version_5010000)
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhar...@impsec.org FALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Activist: Someone who gets involved.
Unregistered Lobbyist: Someone who gets involved with something
the MSM doesn't approve of. -- WizardPC
-----------------------------------------------------------------------
15 days until Bill of Rights day
