On 11/30/2014 10:59 AM, Reindl Harald wrote:
Am 30.11.2014 um 19:44 schrieb Ted Mittelstaedt:
This issue has been discussed here:
http://askubuntu.com/questions/554537/argument-perl-version-isnt-numeric-in-numeric-ge-at-eval-534-line-1
There is a link to patches for 2 Perl modules that turn off
the warnings. Worked for me when I applied those patches.
unacceptable workaround
frankly doing so may get you fired because you risk to break other
packages from the operating system with unknown side-affects and
recommend such actions should start with a big warning
* Fedora 20 is one of the most recent OS environments
* SpamAssassin 3.4.0 is the recent upstream version
* Perl 5.18.4 is recent (Fri Oct 03 2014)
"if perl_version >= 5.010000" must not throw warning with perl 5.18.x
nobody right in has mind is patching perl-modules installed with the OS
package-managment in case of recent SA installed with the
package-managment to work around broken rules on a production server
This is an issue of degrees. Those patches came off the SA distro
they are not some 3rd parties idea of a great change that ought to be
made in SA. When the next version of SA is released those will be
incorporated in it - and if you run updates on your OS, assuming
your package maintainers are following the new releases of SA - your
going to get them eventually.
So your going to have to deal with those changes eventually as well as
any "unknown side effects"
the issue was introduced with SA rule-updates and has to be fixed there
When the fix to allow older SA versions to silently accept the new
rule updates is a simple TEXT modification of 2 text Perl modules, you
are overreacting.
I agree that making such a change on a production server for something
like the operating system that is used by -everything- is risky. In
that case, perhaps it would have to rise to the importance of an
emergency security hole that was just discovered, for an out-of-band
patch to be made.
And of course, it was a bit too fast to make that change in SVN and not
give it a longer time to "cook" and for various distros to get updated
with it.
But in this case, you can make this MINOR change during an off-period,
give it 15 minutes and your going to know if it suddenly sends the CPU
to 100% or something, and you can pull it right back out ASAP.
The ENTIRE REASON that Perl modules are written in text and parsed
IS SO THEY CAN BE EASILY MODIFIED. That's the whole point of Perl.
This is a minor change to Conf.pm and Parser.pm. Those 2 modules are
only used in SA. Download and read the patches and decide if they are
significant or not.
Ted
On 11/30/2014 4:42 AM, Reindl Harald wrote:
Am 30.11.2014 um 05:39 schrieb John Hardin:
On Sun, 30 Nov 2014, Reindl Harald wrote:
Am 29.11.2014 um 23:27 schrieb John Hardin:
However, it is a *warning*, not a fatal error. And it's better than
the
rule killing lint and blocking sa-update completely on an install
that
uses an older perl
don't get me wrong but this *warning* triggers cron mails and spits
messages in case of every SA related command - that's unacceptable and
in fact worser than without that check
before *only* outdated perl versions where affected, now it hits also
recent Fedora setups working before without any warning and with that
rule included
As I said, I underestimated the reaction to doing that.
if that rule can't work in most environments and not made
conditionally it has to be dropped at all because it has more
drawbacks than benefits
It has already been commented out in my sandbox.
But this effectively means we cannot add new features to SA
conditionals
because they might do this to older installs
which new features?
which newer perl?
spamassassin-3.4.0-7.fc20.x86_64
perl-5.18.4-291.fc20.x86_64
that "fix" for older versions is just broken and leads to warnings on a
recent SA with a recent perl while as first people with outdated setups
complained all was fine here
