When emerging some packages with --quiet and any of them is interactive, all of them will generate non-quiet output. Reproducible: Always Steps to Reproduce: $ emerge -aq1 app-emulation/virtualbox-bin sys-apps/coreutils This combination of packages was chosen for demonstration purposes, the actual command that made me notice was sudo emerge -aqvNDu --with-bdeps y @world Actual Results: [ebuild U ] sys-apps/coreutils-7.5 [7.4] [ebuild U ] app-emulation/virtualbox-modules-3.0.8 [3.0.6] [ebuild I U ] app-emulation/virtualbox-bin-3.0.8 [3.0.6-r1] Would you like to merge these packages? [Yes/No] >>> Sending package output to stdio due to interactive package(s): app-emulation/virtualbox-bin-3.0.8 >>> Verifying ebuild manifests >>> Starting parallel fetch >>> Emerging (1 of 3) sys-apps/coreutils-7.5 >>> Downloading 'http://de-mirror.org/distro/gentoo/distfiles/coreutils-7.5.tar.gz' [...] Expected Results: [ebuild U ] sys-apps/coreutils-7.5 [7.4] [ebuild U ] app-emulation/virtualbox-modules-3.0.8 [3.0.6] [ebuild I U ] app-emulation/virtualbox-bin-3.0.8 [3.0.6-r1] Would you like to merge these packages? [Yes/No] >>> Sending output of interactive package(s) to stdio: app-emulation/virtualbox-bin-3.0.8 >> Verifying ebuild manifests >>> Emerging (1 of 3) sys-apps/coreutils-7.5 >>> Installing (1 of 3) sys-apps/coreutils-7.5 [...] When requesting e.g. a quiet world update, a single interactive package should not make the whole process unneccessarily verbose. In this case even virtualbox-bin could have been merged quietly as the license has been accepted before.
(In reply to comment #0) > When requesting e.g. a quiet world update, a single interactive package should > not make the whole process unneccessarily verbose. In this case even > virtualbox-bin could have been merged quietly as the license has been accepted > before. Agreed. You might be interested in the --accept-properties=-interactive option which is in portage-2.2_rc44 (bug 265267).
*** Bug 304957 has been marked as a duplicate of this bug. ***
This has become relevant again with the introduction of USE=modules-sign and USE=secureboot. The used signing key may require a passphrase, however when --jobs>1 or --quiet-build is enabled we cannot see the prompt for the passphrase. Enabling PROPERTIES=interactive in the relevant eclasses comes with the major drawback that now --jobs=1 is forced. Earlier I was thinking that what would be really useful is something like ebegin/eend that specifies that whatever is in between is interactive and should be sent to stdio. This allows ebuilds and eclasses to very precisely define what is interactive. But of course this becomes complicated when we have to ensure with some lock file that only one package at the time enters the interactive ebegin. @Zac do you know if this is feasible at all? Or do you have any other ideas to handle this situation.
(In reply to Andrew Nowa Ammerlaan from comment #3) > @Zac do you know if this is feasible at all? Or do you have any other ideas > to handle this situation. I suppose we can make the job Scheduler transition back and forth between interactive and non-interactive modes, so that the number of jobs is limited to 1 only when there is an interactive job running. This will likely involve an adjustment to the Scheduler's _can_add_job method like bug 934382.
(In reply to Zac Medico from comment #4) > I suppose we can make the job Scheduler transition back and forth between > interactive and non-interactive modes, so that the number of jobs is limited > to 1 only when there is an interactive job running. This will likely involve > an adjustment to the Scheduler's _can_add_job method like bug 934382. The transitions between interactive and non-interactive modes will be similar to the transitions that occur in order to mitigate fragile states when merging system packages for bug 256616, where --jobs effectively drops to 1 while system packages are merging.
