Hey, frankly I thought this kind of information is related to debugging, not something I want to see everytime I type some emerge operation. Would there be an easy way to make it a configure option via EMERGE_DEFAULT_OPTS for example? Same way as --nospinner is implemented? I'd be fine with an opt-out option obviously.
Can't you just not use --verbose...?
Do you really have zero respect towards your fellow developers to be wasting their time with bugs like this?
(In reply to Sam James from comment #1) > Can't you just not use --verbose...? Then again verbose is nice to see use flags on deps. (In reply to Michał Górny from comment #2) > Do you really have zero respect towards your fellow developers to be wasting > their time with bugs like this? I appreciate all the work that goes into portage, Gentoo and open source in general, but I don't have to like every change that happens. In my opinion I provided a nice compromise for everyone. But if that's an absolute no, I can revert the commit locally too.
If you move it to --debug, now users that want to see the information need to pass --debug and its very verbose (prints literally thousands of lines of output.) - I'm not sure any program really provides a per-line level of configuration on the lines emitted; as a general practice. - Most programs have some kind of verbosity level (e.g. more -v's means more output.) - Some programs have some kind of trace-ability, so you can get more detail information. E.g. strace -e trace=<expr> or curl --trace-time or curl --trace=<dumpfile>, or glogs --vmodule which only logs specific compilation units. I'd rather advocate for one of these more standard approaches. Structurally for example, imagine if emerge took a --trace-time option (and -v set --trace-time) and then --trace-time dumped...the time of each phase or op. Then you could run "emerge -v <whatever> --no-trace-time" to get what you wanted. That being said, this all requires a bunch of patches that are unlikely to materialize without significant effort.
> I appreciate all the work that goes into portage, Gentoo and open source in > general, but I don't have to like every change that happens. In my opinion I > provided a nice compromise for everyone. But if that's an absolute no, I can > revert the commit locally too. No, you didn't. What you're doing is wasting a number of people's time on "I don't like one extra line in output" and demanding that we supplement a 6-line change with much bigger logic to add a fancy command-line option just for you (and possibly a few other people who are picky enough to complain about one more line of output but at least have the common decency not to bother others about it).
(In reply to Michał Górny from comment #5) > > No, you didn't. What you're doing is wasting a number of people's time on > "I don't like one extra line in output" and demanding that we supplement a > 6-line change with much bigger logic to add a fancy command-line option just > for you (and possibly a few other people who are picky enough to complain > about one more line of output but at least have the common decency not to > bother others about it). I provided feedback to a new surprising feature, don't feel like there was a "demand" although I can see how the "opt-out" suggestion may seem like it. If you read the opening post carefully there's a question, "Would there be an easy way to make it a configure option?" As I also said, if it's too hard or bothersome, I can keep reverting it locally until I'm either fine with it, or gonna switch to some other package manager.
Sometimes running in debugging mode will print a lot more info than shown here (one line) or might introduce additional runtime overhead (in this case it is just write and read to one variable that takes almost no time).
