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