1 |
Amadeusz Żołnowski wrote: |
2 |
> Excerpts from Dale's message of 2011-11-14 13:43:36 +0100: |
3 |
>> Amadeusz Żołnowski wrote: |
4 |
>>> Excerpts from Dale's message of 2011-11-14 13:17:28 +0100: |
5 |
>>>> Here is some feedback then. I liked it the way it was. When a |
6 |
>>>> build fails, I do a one of install of that package and I like to |
7 |
>>>> see the output. Why, because sometimes it gives me a hint as to |
8 |
>>>> why it failed or something I can google for. |
9 |
>>> If it fails you get tail of build.log, so you see it anyway. |
10 |
>> That doesn't always go back far enough tho. I have on my new rig seen |
11 |
>> the failure be as far back as a couple hundred lines. |
12 |
> Well, don't say that if problem is hundreds lines back you search it in |
13 |
> that output. I'd use for that purpose "less build.log" anyway. |
14 |
> |
15 |
> |
16 |
|
17 |
If emerge puts it on the screen like it always has, I won't need to go |
18 |
to any build.log. It will be there on the screen already since I have |
19 |
history set to save everything. That just means this change is going |
20 |
to cause users to do even more to find out what is broke. That could |
21 |
lead to posts on the forums or mailing lists where people have a build |
22 |
to fail and very little if any info since there is not much on the screen. |
23 |
|
24 |
As I mentioned in another post. Users expect things to work like they |
25 |
always have. That is my point. There is really no reason to change |
26 |
this. It doesn't change what portage does under the hood at all. The |
27 |
old way does help the user tho. It has been a while but I have had |
28 |
compiles to freeze or loop. No output means it would sit there for a |
29 |
good long while, possibly doing nothing. |
30 |
|
31 |
Dale |
32 |
|
33 |
:-) :-) |