During a regular world update, when building spamassassin-3.4.1-r8, I got the following query for user input: >>> Starting src_configure What email address or URL should be used in the suspected-spam report text for users who want more information on your filter installation? (In particular, ISPs should change this to a local Postmaster contact) default text: [the administrator of that system] This goes contrary to my assumption / experience, that all installations should work without any direct user-interaction. My previous spamassassin version was 3.4.0-r1 and I am using paludis-2.6.0.
SpamAssassin uses Perl's MakeMaker, so the line PERL_MM_USE_DEFAULT=1 emake is intended to avoid exactly what you're experiencing. I've grepped through the tree, and the only other usage like that is when perl-module eclass does, export PERL_MM_USE_DEFAULT=1 <blah blah blah> Maybe there's a difference in the way that Paludis and Portage handle passing variables to emake. Can you try to change PERL_MM_USE_DEFAULT=1 emake to either emake PERL_MM_USE_DEFAULT=1 or export PERL_MM_USE_DEFAULT=1 emake in the ebuild, and see if that helps? If it does, I'll fix it in a new revision.
Indeed the variable PERL_MM_USE_DEFAULT does yield the correct behavior. But the problem I reported occurs not in src_compile, but in src_configure. More specifically in the lines perl Makefile.PL \ PREFIX=[...] So putting export PERL_MM_USE_DEFAULT=1 at the beginning of src_configure, solves the problem.
The fact that this worked in portage was a lucky coincidence. It's now exporting PERL_MM_USE_DEFAULT=1 earlier so it disables the prompts regardless of the controlling TTY and STDIN: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c0507ac8482881f315fc92b4b6f89fc58bd4b1f9 I made the change in-place to the -r10 ebuild, so you might have to wait a few hours for the fix to show up. Please let me know if you still have any problems. Thanks to Kent Fredric who pointed out that the interactive prompt was dependent on the controlling TTY and file descriptors.
