Amadeusz Żołnowski posted on Sun, 13 Nov 2011 14:04:49 +0100 as excerpted:
> Excerpts from Thomas Sachau's message of 2011-11-13 13:39:17 +0100:
>> This can be argued from either side, if the default is verbose, you can
>> make it quiet in the default emerge opts and the other way round. So
>> this is no argument for or against default quiet build in my eyes.
> Not every user studies manpages of every program they use. Making
> --quiet-build=y default is a *benefit* for people who don't care much.
> If somebody cares about the output probably will care to read the
> manpage how to make it verbose. How many emerge users know that option?
Surely this is to a large degree bikeshedding. Whatever the default is,
the user can change it as desired, and if a Gentoo user isn't comfortable
with that, they *REALLY* need to question whether they've made the best
choice possible choosing Gentoo, based on their needs and goals.
Similarly, someone mentioned how time consuming it could be to change the
option in a high-unit-number installation, but I'd suggest that if such
is the case, the person doing it really needs to rethink their approach
in the first place, and if this is what finally triggers that, well...
>> As already said, it is nice to see, where a build hangs, when some
>> specific task does take longer and until now, it was easy to see, just
>> watch the output. With the new default, you cannot say, what it does,
>> where it may be or if there are many things or just one line taking
>> much time. And you additionally have to go to the build.log manually to
>> actually see something.
> Build output tells almost nothing about the progress (except of cmake).
> But --quiet-build=y actually gives more useful and handy info: what is a
> total progress.
>> In addition, it is also nice to just a quick look into the console to
>> see, what and where it failed.
> When it fails, it prints tail of build.log.
While I already stated that I believe this to be bikeshedding, here's my
take, hinted at earlier.
The previous defaults made perfect sense to me already. Parallel emerge
jobs already puts portage in quiet mode, and that's what most people who
care (see my point above about whether this is the right distro choice or
not) should already be using. That default makes sense, since otherwise
the output would be jumbled anyway.
1-at-a-time merge defaults are therefore where the question is. Two
positions could be taken here. If it is argued that those who care will
already be using parallel mode in most cases, and that those who care but
that can't be bothered to switch their defaults really should be
questioning whether gentoo is an appropriate choice in the first place,
then a "noisy" default for 1-at-a-time makes sense too, because the only
time most (who care) will see it is when they're actually troubleshooting
something and thus deliberately using 1-at-a-time mode, in which case the
higher level of detail by default for that mode makes the the most sense.
OTOH, it could equally be argued that quiet mode /does/ speed things up
slightly and/or lessen CPU requirements for output scrolling, so that
mode should be the default, because again, those who care can always
change it anyway, and the Gentoo presumption should be that they will.
But because I /do/ believe it's bikeshedding, since it's easily
configurable in any case and the gentoo assumption must be that we expect
people to configure it if desired, or indeed, what's the whole point of
running gentoo anyway, my personal preference is to revert to the way
things were, quiet parallel emerge jobs, "noisy" 1-at-a-time, just
because I'm selfish and that happens to be what'll require no changes on
my part, since it's the previous and thus already assumed behavior built
into my scripts.
But since the change is already made and changing the assumption of my
scripts is as trivial as it is, no skin off my nose if Zach simply sticks
with the change already made.
Bikeshed away! =:^)
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman