Summary: | sys-apps/portage-2.2_rc44: emerge --quiet resorts to non-quiet output for all packages if any of them has PROPERTIES="interactive" | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Malte Starostik <bugs> |
Component: | Core - Interface (emerge) | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | enhancement | CC: | andrewammerlaan, esigra, shiningarcanine |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://github.com/gentoo/gentoo/pull/32966 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 184128 |
Description
Malte Starostik
2009-10-08 13:32:30 UTC
(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. |