John, if you make it a warning - warn ONCE not ever blessed time the file is run
and CLEARLY state this is a warning only and is not fatal. PLEASE PLEASE PLEASE
{o.o}
On 2014-11-30 11:11, John Hardin wrote:
On Sun, 30 Nov 2014, Dave Pooser wrote:
On 11/30/14 12:34 PM, "Paul R. Ganci" <ga...@nurdog.com> wrote:
So just so I understand something is it expected that those of us with
RHEL 5.11 and RHEL 6.6 servers are expected to upgrade our perl versions
just for spamassassin's sa-update? The whole idea of running servers
with those versions of server software is for stability.
Yep.
Um, nope. The whole point to this was to allow SA rules to deal gracefully with
older perl versions.
The problem at hand is not caused by the perl version that is installed, and
upgrading the version of perl will not fix it; it's caused by a single rule that
uses recent perl syntax (and which caused sa-update to fail lint on perl 5.8.8)
trying to avoid problems on older perl by using a brand new SA feature, and use
of that feature on older SA generates a warning.
I apologize, I thought that a warning was preferable to a fatal error, and I
underestimated the impact of the warning, and have again completely disabled the
rule in question until the situation is resolved, however that ends up
happening. This change did not go out in the last update, hopefully it will be
in the next.
And the whole point of running SpamAssassin with sa-update is for
flexibility and agility. The two goals are necessarily in conflict. So...
Looks like you have a few options:
1) Don't run SA on RHEL
2) Run SA on RHEL but turn off sa-update and sacrifice automated reaction
to new spam in the interest of keeping your system static
3) Run SA on RHEL but upgrade perl and SpamAssassin using
third-party-packages or update from source
4) Run SA on RHEL with system perl and system SpamAssassin, run sa-update
with output redirected to /dev/null, and write your own monitoring script
to tell you if sa-update broke spamd
5) Run SA in some kind of container or VM so you can optimize for
spamassassin without tainting the purity of your RHEL install
6) You patch, or RHEL (et. al.) patches the official SA distro package,
with the tiny change that implements perl_version support in conditionals and
avoids this warning, so that rule development can safely use perl features from
newer versions of perl without risking a *fatal* error in sa-update at sites
using older versions of perl.
7) SA implements some other more-complex, more-backwards-compatible method of
checking the version of perl in conditionals, such as a new function that can be
checked in a can().
