| 1 |
2011/12/4 Chí-Thanh Christopher Nguyễn <chithanh@g.o>: |
| 2 |
> Among the people preferring to see build output, making -v control the |
| 3 |
> default seems to be considered an acceptable compromise. So wouldn't |
| 4 |
> that be great? Hiding build output by default, while still satisfying |
| 5 |
> most critics of this idea. |
| 6 |
|
| 7 |
I don't care that strongly about the defaults since I can change them |
| 8 |
(though I'd like them to be reasonably sane so that people take us |
| 9 |
seriously). |
| 10 |
|
| 11 |
However, making -v control the output seems like a problem, unless |
| 12 |
there is some way to undo this. A typical workflow for me is to run |
| 13 |
emerge -auDNv world to see what is going to build, and then hitting |
| 14 |
enter to accept it. I want to get the verbose USE info with -a/p, but |
| 15 |
I don't really care to see build logs flying across the screen. So, |
| 16 |
overloading a single flag to do both sounds problematic unless you |
| 17 |
also allow the quiet flag to override it back. That seems complicated |
| 18 |
to me. |
| 19 |
|
| 20 |
That raises another portage flags issue - the fact that we need so |
| 21 |
many options to do "the right thing." Now, I'll argue the right thing |
| 22 |
is subjective so we do need to be able to control it. However, it |
| 23 |
seems like we should be able to agree on the best setting for |
| 24 |
general-purpose updates is, and make that a single setting. |
| 25 |
|
| 26 |
As far as opinions vs facts go - in software design the only real |
| 27 |
facts are whether a particular design satisfies or does not satisfy a |
| 28 |
particular requirements specification, or dry measures like |
| 29 |
benchmarks/scalability/etc. Whether a particular design is "better" |
| 30 |
is always a matter of opinion, unless better simply means satisfying |
| 31 |
more requirements or some other objective measure. That then just |
| 32 |
begets the question as to whether one set of requirements is better |
| 33 |
than another, and that is just vodoo. Actually, even stating as a |
| 34 |
"fact" whether a program even meets a requirement is extraordinarily |
| 35 |
difficult for all but the most trivial programs - you can't even prove |
| 36 |
conclusively whether the program will always terminate short of |
| 37 |
exhaustively testing all possible input. |
| 38 |
|
| 39 |
That's why we could perpetuate this thread for six months and never |
| 40 |
really resolve the issue, and ultimately sometimes you just need a |
| 41 |
council to weigh in with their opinion, when everybody can't live with |
| 42 |
the maintainer's opinion. |
| 43 |
|
| 44 |
Rich |
Archives