You mentioned that you removed the spamassassin dependency because it is detected at runtime, but attempting to start amavisd (with ebuild-provided config) without it yields a "Can't locate Mail/SpamAssassin.pm in @INC" error and amavisd fails to start.
From Line 18 of the config file: # @bypass_spam_checks_maps = (1); # uncomment to DISABLE anti-spam code Do you think I need to do more with the ebuild? If so, what? I could issue a warning statement to urge the user to either install SpamAssassin or disable it in the config. Or I could actually change the config file with sed, but I'm not sure that's the right course of action. If a user doesn't have SpamAssassin installed, that doesn't mean he's not going to install it later. I should mention that amavisd uses SpamAssassin to work with DSPAM, if DSPAM is desired. So if you were looking to use DSPAM without SpamAssassin, amavisd can't do it. And it doesn't look like amavisd spam checks will ever work without SpamAssassin according to RELEASE_NOTES: "Eventually DSPAM support should be removed from amavisd-new, as soon as SA will be able to call it on its own." What's everyone's opinion on this issue?
Perhaps something like: unless (eval { require Mail::SpamAssassin; }) { @bypass_spam_checks_maps = (1); } so that it really is automagically detected. Would that work?
It's not really that simple, unfortunately. Amavisd makes a good effort to load portions of the SpamAssassin module that need to be loaded before a chroot. Then it loads the remaining components after the chroot. To add something like that would break a lot of the complex functionality. In addition, the @bypass_spam_checks_maps =(1) sets an internal variable $extra_code_antispam, which when disabled, actually disables large chunks of code in amavisd, reducing memory footprint and processing time.
Ah...well, it was just a thought. perl really should provide a module-existance test. Oh well. In that case, since the Gentoo ebuild philosophy is that it's supposed to work out of the box, how about a pkg_config that use perl -e to run a similar test and uncomments the line in question if SpamAssassin is not found (accompanied by an ewarn that ebuild <file> config needs to be run)? Maybe even a pkg_postinst instead? Or better yet a pkg_preinst that conditionally fixes it in the workdir so that the fixed version is packaged.
Ah heck, wouldn't a "spamassasin" USE variable simplify this greatly? That way, the user is sure to get what (s)he wanted, including dependencies.
Ok I added some checking for mail-filter/spamassassin that uncomments the line in the provided config file, then notifies the user. I like to be conservative with use flags, because they can quickly get out of control. Let me know what you think about this solution, but I think it addresses the problem in a simple manner. As always, thank you for the bug report :)
Works great. And *of course* that's a better way to detect. I had a "duh" moment. :P
