Try installing Mail::Sender and you'll see that it expects input for configuration. Then, you'll see emerge try to repeat the process and apparently get stuck. It's really waiting for you to reenter the configuration details again, but the output doesn't show up until after you've completed entering information, so you don't know what you should enter unless you scroll up to what you did earlier. I have an ebuild that doesn't go through g-cpan.pl that takes care of the problem. I'll attach it, just in the rare case that this is the right solution. I didn't submit it originally because I found a comment that stated Perl modules are only included in Portage if some other application depends on them. I'm just including it to show this error can be worked around effectively. Reproducible: Always Steps to Reproduce: 1. g-cpan.pl Mail::Sender 2. Hit <Enter> to take the default configuration the first time. 3. Watch as the script is waiting for input without printing any prompting output first. Expected Results: Displayed the output on stdout so I knew to hit enter.
Created attachment 25948 [details] Ebuild that works around this issue Here's the ebuild I mentioned when opening the bug.
Is this still an issue with app-portage/g-cpan?
This is always going to be an issue, forever and ever and ever, or at least until every module author around invokes some silent treatment for noninteractive sessions. There's really nothing that can be done for it - your using g-cpan to avoid us adding an ebuild, and this is one of the things we have to work around when we create ebuilds. I don't know that this will ever be fixable for all packages in cpan.
Thanks for quick reply. This probably should be marked CANTFIX then, unless you want to put yet another ebuild into portage. ;p
Mass re-assign.
close()ing STDIN will at least avoid waiting for timeouts. Are there any adverse side effects from doing this? --- g-cpan.orig 2005-10-02 02:02:23.000000000 -0700 +++ g-cpan 2005-10-02 04:06:08.879675050 -0700 @@ -47,6 +47,10 @@ "perl-tools", "perl-xml", "perl-dev" ); +# some distributions ask questions. close()ing STDIN will short-circuit +# any reads they try to do from STDIN +close STDIN or die $!; + ############################### # Command line interpretation # ###############################
Re-assign.
unfortunately, this ebuild is in portage at this point. as for adverse affects, i'd be worried about how this stomps on modules that require a y|n answer (and where you don't necessarily want the default)(but that's me talking without even testing)
closing this as can't fix. the proposed solution breaks other functionality; this is an acknowledged shortcoming of g-cpan.
