Summary: | mail-filter/spamassassin-2.64 stores absolute perl binary path in build | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Spider (RETIRED) <spider> |
Component: | New packages | Assignee: | Gentoo Perl team <perl> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | fuzzyray, gentoo-bugger, rockoo, tisphie |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | patch against spamassassin-2.64.ebuild |
Description
Spider (RETIRED)
2004-08-30 10:46:32 UTC
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.) |