1 |
On 2011.12.05 13:25, Rich Freeman wrote: |
2 |
> 2011/12/4 Chí-Thanh Christopher Nguyễn <chithanh@g.o>: |
3 |
> > Among the people preferring to see build output, making -v control |
4 |
> the |
5 |
> > default seems to be considered an acceptable compromise. So |
6 |
> wouldn't |
7 |
> > that be great? Hiding build output by default, while still |
8 |
> satisfying |
9 |
> > most critics of this idea. |
10 |
> |
11 |
> I don't care that strongly about the defaults since I can change them |
12 |
> (though I'd like them to be reasonably sane so that people take us |
13 |
> seriously). |
14 |
> |
15 |
> However, making -v control the output seems like a problem, unless |
16 |
> there is some way to undo this. A typical workflow for me is to run |
17 |
> emerge -auDNv world to see what is going to build, and then hitting |
18 |
> enter to accept it. I want to get the verbose USE info with -a/p, |
19 |
> but |
20 |
> I don't really care to see build logs flying across the screen. So, |
21 |
> overloading a single flag to do both sounds problematic unless you |
22 |
> also allow the quiet flag to override it back. That seems |
23 |
> complicated |
24 |
> to me. |
25 |
> |
26 |
> That raises another portage flags issue - the fact that we need so |
27 |
> many options to do "the right thing." Now, I'll argue the right |
28 |
> thing |
29 |
> is subjective so we do need to be able to control it. However, it |
30 |
> seems like we should be able to agree on the best setting for |
31 |
> general-purpose updates is, and make that a single setting. |
32 |
> |
33 |
> As far as opinions vs facts go - in software design the only real |
34 |
> facts are whether a particular design satisfies or does not satisfy a |
35 |
> particular requirements specification, or dry measures like |
36 |
> benchmarks/scalability/etc. Whether a particular design is "better" |
37 |
> is always a matter of opinion, unless better simply means satisfying |
38 |
> more requirements or some other objective measure. That then just |
39 |
> begets the question as to whether one set of requirements is better |
40 |
> than another, and that is just vodoo. Actually, even stating as a |
41 |
> "fact" whether a program even meets a requirement is extraordinarily |
42 |
> difficult for all but the most trivial programs - you can't even |
43 |
> prove |
44 |
> conclusively whether the program will always terminate short of |
45 |
> exhaustively testing all possible input. |
46 |
> |
47 |
> That's why we could perpetuate this thread for six months and never |
48 |
> really resolve the issue, and ultimately sometimes you just need a |
49 |
> council to weigh in with their opinion, when everybody can't live |
50 |
> with |
51 |
> the maintainer's opinion. |
52 |
> |
53 |
> Rich |
54 |
> |
55 |
> |
56 |
|
57 |
Rich, |
58 |
|
59 |
I'll stir the pot a little. I'm only replying here as I want to bring |
60 |
out a few facts. |
61 |
|
62 |
1. When portage was created, almost all of us used to build on single |
63 |
CPU/core machines. |
64 |
|
65 |
2. Builds would progress at a speed where the portage output could be |
66 |
read as the build progressed. |
67 |
|
68 |
3. A few sad individuals (including me) could read the portage output |
69 |
and know where a build was. |
70 |
|
71 |
4. The number of parallel makes was low enough for any errors to still |
72 |
be in the back buffer. |
73 |
|
74 |
5. CPUs have grown faster over the years, so the build output has |
75 |
scrolled by faster. |
76 |
|
77 |
|
78 |
Opinion. |
79 |
a) With my current system, postage output scrolls too fast for me to |
80 |
read. |
81 |
|
82 |
b) Portage on screen output is now useless to me, since I have to look |
83 |
in the build log for errors anyway. |
84 |
|
85 |
c) This default is well overdue a change to keep up with the times. |
86 |
|
87 |
Do we want Gentoo to be first into the future and last out of the past? |
88 |
|
89 |
-- |
90 |
Regards, |
91 |
|
92 |
Roy Bamford |
93 |
(Neddyseagoon) a member of |
94 |
elections |
95 |
gentoo-ops |
96 |
forum-mods |
97 |
trustees |