1 |
El sáb, 23-06-2012 a las 17:53 +0100, Ciaran McCreesh escribió: |
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 |
Did you send this proposal seriously or only to troll comparing it with |
39 |
what you think tommy did with multilib thread? |
40 |
|
41 |
If this is seriously, could you explain more how paludis behave in this |
42 |
case? Looks like it treats SLOT with major number as latest version, |
43 |
that is not always true and I don't understand why it should be always |
44 |
true as there are cases where upstream could release newer 3.0.x |
45 |
releases that are really newer than 3.1.x versions. |
46 |
|
47 |
Current -r300/200 stuff shouldn't break as it's only used to slot |
48 |
libraries and that libs will only be installed when some app RDEPENDs on |
49 |
them. |
50 |
|
51 |
> |
52 |
> > > That's covered in the devmanual and in the user documentation, so |
53 |
> > > there's no need to repeat it here. |
54 |
> > |
55 |
> > Ever heard about references. They are good, if you don't like to |
56 |
> > repeat what is written, but which are necessary context to understand |
57 |
> > what you are writing. You should use them for the sake of |
58 |
> > understanding, if you are to lazy to write it out again. |
59 |
> |
60 |
> Please take a look at the proposal for EBUILD_PHASE_FUNC, and say where |
61 |
> it references what "phase functions" are, or the proposal for usex and |
62 |
> say where it references what "use flags" are, or the proposal for |
63 |
> silent rules where it references what "econf" is. |
64 |
> |
65 |
> > >> To me, it doesn't solve the root cause, but actually I can't judge |
66 |
> > >> this, because I am missing a description of what is really going |
67 |
> > >> wrong. |
68 |
> > > |
69 |
> > > As I've already said, this isn't about solving the root cause. It's |
70 |
> > > about reducing the impact of damage that's already been done until |
71 |
> > > the root cause is solved properly. |
72 |
> > |
73 |
> > My clear vote is No. We shouldn't implement anything which allows bad |
74 |
> > coding anywhere, just for the sake of having it "solved" now. |
75 |
> |
76 |
> The bad coding has already happened. Are you volunteering to revert the |
77 |
> Ruby virtuals? |
78 |
> |