I propose the following emerge verbosity levels: -q - no output at all -v0 - minimal output (default), e.g. current --quiet-build=y -v1 - print USEflags etc. (preserves current behavior of the flag -v) -v2 - more verbose, print all elog messages as they come -v3 - very verbose, print all build output, current --quiet-build=n Every one of the more verbose levels include all of the output of the previous levels in addition to their own. This would make managing emerge verbosity more intuitive and straightforward by making flags consistent (in contrast to the current -q, -v, --quiet-build). These options are also much shorter than --quiet-build, requiring less typing on command line for temporary overrides. Option -v0 would be useful if, e.g., in DEFAULT_EMERGE_OPTS is set -v1 and user wants to override that temporary, for example when giving emerge --info for bug reports. The defaults could be disputable, but this proposition doesn't address this. The goal is to have a consistent CLI for managing emerge verbosity, with the added bonus that it is backwards compatible with the current -v option. Not giving any -v option would be the same as -v0. Giving -v flag without any number would be the same as giving -v1 (current behavior). The syntax might be a bit different, e.g., instead of using numerical levels one could use repeated option (-vvv), but I think numerical levels are easier to use (and implement?) especially if one wants to override some verbosity level with -v0 (no verbosity). Reproducible: Always
I think the verbosity handling in emerge could use an overhaul. For your list of levels: I think the general idea makes sense. Take a look at bug 391323 for some levels of verbosity. One problem I see with this is, that it couples merge list verbosity and build verbosity. Currently it even makes sense to have to specify -q and -v at the same time, because they do different things. Some things missing from your list that are affected by -q/-v are the warnings and explanations that come along with blockers / slot conflicts / preserved libs / ... Imo it would make sense to have at least two independent verbosity levels. One for the merge list and one for the build output.
I think what he wants in bug 391323 is my proposed -v2 to be -v0 and maybe one additional level of verbosity where the file system modifications are shown (merged files) while build info still is hidden. Some of the points from that bug could be merged with this proposition, but the rest could be treated independently. The coupling of emerge build and install messages is intentional, because I think that it is the same concept only different verbosity level. Besides build system verbosity is controlled outside of emerge and I think that should stay like that. So we could add extra level: -q - no output at all -v0 - minimal output (default), e.g. current --quiet-build=y -v1 - print USEflags etc. (preserves current behavior of the flag -v) -v2 - more verbose, print all elog messages as they come, fetch progress -v3 - show installed files -v4 - very verbose, print all build output, current --quiet-build=n or just replace the original -v2 with "show installed files" if it is decided that all elog messages should be shown at -v0 (bug 391323) or -v1. In that case move showing fetch progress with it (with parallel fetch it is still hidden). It might be a good idea to show some fetch progress even with parallel fetch, e.g. by giving "downloaded 3/7 packages.." As for messages for blockers / slot conflicts / preserved libs / ... imo they should be shown at -v0, because they are something that require users attention in any case.
For fine-grained control there could be a separate set of flags for controlling verbosity on a per-phase basis, e.g. --verbose-configure --verbose-test which would override -v setting for the respective src_* phases. This would still make the behavior more consistent and predictable, but the main verbosity control would be handled trough -v flags, and one could also say to emerge to shut up using -q. If such a feature is deemed desirable, a separate feature request could be opened.
