spider@Darkmere> head -n3 /usr/bin/spamassassin #!/usr/bin/perl5.8.4 -w spider@Darkmere> ls -la /usr/bin/perl* lrwxrwxrwx 1 root root 9 Aug 29 05:50 /usr/bin/perl -> perl5.8.5 -rwxr-xr-x 1 root root 1147464 Aug 29 05:50 /usr/bin/perl5.8.5 -rwxr-xr-x 1 root root 37274 Aug 29 05:50 /usr/bin/perlbug -rwxr-xr-x 1 root root 17953 Aug 29 05:50 /usr/bin/perlcc -rwxr-xr-x 1 root root 224 Aug 29 05:50 /usr/bin/perldoc -rwxr-xr-x 1 root root 11661 Aug 29 05:50 /usr/bin/perlivp This breaks mailfiltering on all systems that upgrade perl.
I ran into this one as well.
Patch in progress...
Created attachment 39646 [details, diff] patch against spamassassin-2.64.ebuild Here's the patch which works around the issue. I'll see if I can make the detection a bit more intelligent for 3.1.0.
Reassigning to rac so he can commit the fix :)
Reassigning to the Perl herd, maybe somebody wants to create a 2.64-r1 ebuild with this fix to bridge the time till 3.0 is marked stable?
*** Bug 73612 has been marked as a duplicate of this bug. ***
Not just the perl-binary path get wrong, but also the lib-path. use lib '/usr/lib/perl5/vendor_perl/5.8.4'; # substituted at 'make' time A re-emerge solves both issues.. Hoping 3.x will make it to stable soon.
The lib path is correct. If you install a perl module, it will go into the versioned path for the perl version you used to install it. Later versions will also look into "older" libs. This is true for every perl module. (And the SpamAssassin apps are bound very tight to their libs.)
Due to bug 64133 SpamAssassin 3.0.2 is on its way to be marked as stable and the bug is fixed in the 3.x ebuild.