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