1 |
On 23.06.2012 18:53, Ciaran McCreesh wrote: |
2 |
> On Sat, 23 Jun 2012 18:47:26 +0200 |
3 |
> Justin <jlec@g.o> wrote: |
4 |
>> On 23.06.2012 18:17, Ciaran McCreesh wrote: |
5 |
>>> On Sat, 23 Jun 2012 18:13:23 +0200 |
6 |
>>> Justin <jlec@g.o> wrote: |
7 |
>>>> Did you read what you wrote and thought about what you request from |
8 |
>>>> others? Probably you better should. |
9 |
>>> |
10 |
>>> Uh huh, and I think we all know there's a huge difference between |
11 |
>>> knowing what versions and slots are and knowing what "a multilib" |
12 |
>>> is. |
13 |
>>> |
14 |
>> |
15 |
>> Might be right, but that doesn't allow you to break your own rules. |
16 |
>> Plus I still don't get the problem of using SLOTS in the way they are |
17 |
>> used now. |
18 |
> |
19 |
> "My own rules" are that enough material is presented that the relevant |
20 |
> people understand it. If you look at simple proposals like usex, silent |
21 |
> rules or EBUILD_PHASE_FUNC, you'll see quite clearly that we ask for |
22 |
> very little in the way of text in cases where the change is easily |
23 |
> understood. |
24 |
> |
25 |
>> And I can't find this out by simply googling. In contrast, an |
26 |
>> explanation of multilib in context of linux distribution and more |
27 |
>> specific gentoo can be found easily. |
28 |
> |
29 |
> Oh really? I was under the impression that there wasn't even general |
30 |
> agreement upon whether or not multilib applied to "C" or to "C, and |
31 |
> Python, and things like it". |
32 |
> |
33 |
>> Stop acting in this arrogant way you are doing right now. |
34 |
> |
35 |
> Come on. Submitting a simple proposal with at least as much detail as |
36 |
> was provided for other, equally simple proposals is "arrogant" now? |
37 |
> |
38 |
>>> That's covered in the devmanual and in the user documentation, so |
39 |
>>> there's no need to repeat it here. |
40 |
>> |
41 |
>> Ever heard about references. They are good, if you don't like to |
42 |
>> repeat what is written, but which are necessary context to understand |
43 |
>> what you are writing. You should use them for the sake of |
44 |
>> understanding, if you are to lazy to write it out again. |
45 |
> |
46 |
> Please take a look at the proposal for EBUILD_PHASE_FUNC, and say where |
47 |
> it references what "phase functions" are, or the proposal for usex and |
48 |
> say where it references what "use flags" are, or the proposal for |
49 |
> silent rules where it references what "econf" is. |
50 |
> |
51 |
>>>> To me, it doesn't solve the root cause, but actually I can't judge |
52 |
>>>> this, because I am missing a description of what is really going |
53 |
>>>> wrong. |
54 |
>>> |
55 |
>>> As I've already said, this isn't about solving the root cause. It's |
56 |
>>> about reducing the impact of damage that's already been done until |
57 |
>>> the root cause is solved properly. |
58 |
>> |
59 |
>> My clear vote is No. We shouldn't implement anything which allows bad |
60 |
>> coding anywhere, just for the sake of having it "solved" now. |
61 |
> |
62 |
> The bad coding has already happened. Are you volunteering to revert the |
63 |
> Ruby virtuals? |
64 |
> |
65 |
|
66 |
|
67 |
I give up. And actually I don't care anymore. |
68 |
|
69 |
When I saw the first people leaving this project, because of all this |
70 |
non social bitching, I thought by myself, this will never happen to me. |
71 |
But the amount of fruitful discussion here is so less compared to the |
72 |
shire amount crap coming through, that it is not worth following it. |
73 |
|
74 |
justin |