Amadeusz Żołnowski schrieb: > 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?
How is that an argument for default quiet build? It is exactly the same argument against default quiet build. If someone does not care, he does not care about the output being verbose or not, so no need to change a default for him. And what does a number of users knowing about an option have to do with a default setting? > > >> 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). > Many packages compile in few minutes on average machine. I hardly ever > experience hangs and if - it's usually for boost. For those few > packages it's no harm to check build.log. You expect people to manually check the build.log just to see, where it hangs? I prefer checking the console, there i can see it directly and dont have to check for the path of the current build.log and then have to additionally open it manually. So your "no harm" is plain wrong, since it takes me more time for doing the same thing as before, while i still see no benefit for the change of the default. > > But --quiet-build=y actually gives more useful and handy info: what is > a total progress. Which user cares about which module is actually being > compiled? He/she cares more which package out of total is being > compiled at the moment. If someone does not care about the current state of a compile, he wont care about the total state either. Beside the point, that you can see the total state in the terminal bar (i hope, i got the right name for that thing).
signature.asc
Description: OpenPGP digital signature
