1 |
On Tue, Sep 29, 2015 at 12:52:41AM +0200, lee wrote: |
2 |
> |
3 |
> Alan McKinnon <alan.mckinnon@×××××.com> writes: |
4 |
> |
5 |
> > On 27/09/2015 21:17, lee wrote: |
6 |
> > |
7 |
> > Fellow, I'm done with you, really. |
8 |
> > |
9 |
> > You hold onto your issues with portage like they were some treasured |
10 |
> > memory of a long-since departed loved one, while all the time apparently |
11 |
> > ignoring the correct valid solutions offeered by kind folks on this list. |
12 |
> > |
13 |
> > Let it go. The devs know about portage output. I don't see you |
14 |
> > submitting patches though. |
15 |
> |
16 |
> You ran out of arguments and remain at insisting that the problem is |
17 |
> known and cannot be fixed because it's too complicated while rejecting |
18 |
> suggestions but asking for patches. So I have no reason to think that |
19 |
> patches would be any more welcome than suggestions, and now even if you |
20 |
> came up with some pointer what to look at (since emerge, for example, is |
21 |
> a wrapper script from which I couldn't see where to start), I wouldn't |
22 |
> waste my time with it. Congratulations. |
23 |
> |
24 |
|
25 |
Someone (I can't remember who, probably Rich Freeman or some other dev) |
26 |
described a problem with the general process of fixing the portage |
27 |
output a while ago. I believe the steps went something like this: |
28 |
|
29 |
1. Think the portage output sucks |
30 |
2. Learn what the output means |
31 |
3. Lose all motivation to improve the output because it is no longer |
32 |
necessary for you |
33 |
|
34 |
The portage output is not as good as it could be, but everyone with the |
35 |
knowledge to fix it doesn't because they neither care (because they |
36 |
understand it) *nor* are they being paid. |
37 |
|
38 |
In my opinion, the portage output is not that bad, in the same way that |
39 |
gcc's error messages are not that bad. They can be difficult to get used |
40 |
to and some of them are absolutely ridiculous, but after using gcc for a |
41 |
while they almost always make sense and are precise. |
42 |
|
43 |
Alec |