| 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 |
Archives