On 2011.12.05 13:25, Rich Freeman wrote:
> 2011/12/4 Chí-Thanh Christopher Nguyễn <email@example.com>:
> > Among the people preferring to see build output, making -v control
> > default seems to be considered an acceptable compromise. So
> > that be great? Hiding build output by default, while still
> > most critics of this idea.
> I don't care that strongly about the defaults since I can change them
> (though I'd like them to be reasonably sane so that people take us
> However, making -v control the output seems like a problem, unless
> there is some way to undo this. A typical workflow for me is to run
> emerge -auDNv world to see what is going to build, and then hitting
> enter to accept it. I want to get the verbose USE info with -a/p,
> I don't really care to see build logs flying across the screen. So,
> overloading a single flag to do both sounds problematic unless you
> also allow the quiet flag to override it back. That seems
> to me.
> That raises another portage flags issue - the fact that we need so
> many options to do "the right thing." Now, I'll argue the right
> is subjective so we do need to be able to control it. However, it
> seems like we should be able to agree on the best setting for
> general-purpose updates is, and make that a single setting.
> As far as opinions vs facts go - in software design the only real
> facts are whether a particular design satisfies or does not satisfy a
> particular requirements specification, or dry measures like
> benchmarks/scalability/etc. Whether a particular design is "better"
> is always a matter of opinion, unless better simply means satisfying
> more requirements or some other objective measure. That then just
> begets the question as to whether one set of requirements is better
> than another, and that is just vodoo. Actually, even stating as a
> "fact" whether a program even meets a requirement is extraordinarily
> difficult for all but the most trivial programs - you can't even
> conclusively whether the program will always terminate short of
> exhaustively testing all possible input.
> That's why we could perpetuate this thread for six months and never
> really resolve the issue, and ultimately sometimes you just need a
> council to weigh in with their opinion, when everybody can't live
> the maintainer's opinion.
I'll stir the pot a little. I'm only replying here as I want to bring
out a few facts.
1. When portage was created, almost all of us used to build on single
2. Builds would progress at a speed where the portage output could be
read as the build progressed.
3. A few sad individuals (including me) could read the portage output
and know where a build was.
4. The number of parallel makes was low enough for any errors to still
be in the back buffer.
5. CPUs have grown faster over the years, so the build output has
scrolled by faster.
a) With my current system, postage output scrolls too fast for me to
b) Portage on screen output is now useless to me, since I have to look
in the build log for errors anyway.
c) This default is well overdue a change to keep up with the times.
Do we want Gentoo to be first into the future and last out of the past?
(Neddyseagoon) a member of