1 |
On Sun, 30 Sep 2012 16:56:56 -0700 |
2 |
Brian Harring <ferringb@×××××.com> wrote: |
3 |
> On Sun, Sep 30, 2012 at 10:53:40PM +0100, Ciaran McCreesh wrote: |
4 |
> > But here's the thing: when you sell something as "pragmatic", what |
5 |
> > you're really saying is "it's wrong, I know it's wrong, and I'm |
6 |
> > going to pretend that wrong is a good thing". Getting it wrong |
7 |
> > should be something you do only after you're sure you can't afford |
8 |
> > get it right; it shouldn't be something you're proud of. |
9 |
> |
10 |
> No, when I say pragmatic, what I'm actually saying is that people who |
11 |
> can't focus on cost/gain, by large, haven't had real jobs (else they |
12 |
> would've had that perfectionism/decreasing gains ground out of them |
13 |
> sooner or later), and are spending their time whacking off chasing a |
14 |
> mythical 'perfect' solution. |
15 |
|
16 |
I don't know whether you're aware of this, but a small number (cost per |
17 |
ebuild) multiplied by a big number (lots of ebuilds) can be larger than |
18 |
a medium sized number (cost of implementing a good solution). I realise |
19 |
this is a sophisticated technique I'm using here, but I assure you |
20 |
multiplication has been used in some industries for a few years now. |
21 |
|
22 |
> Academic wankery, is the short version. You're good at technical, |
23 |
> but you frequently do the academic wanking crap which leads to things |
24 |
> dead-ending... plus wasted time because to you, 'pragmatic' is a |
25 |
> dirty word (compromise? Heaven forbid!). |
26 |
|
27 |
Or looking at it another way: you're so eager to deliver a "compromise" |
28 |
and a "pragmatic" solution (at the expense of ebuild writers |
29 |
everywhere) that you immediately rule out a "good" solution just so |
30 |
you can push the virtues of doing it wrong. Doing it wrong should be a |
31 |
last resort, not something you look to do at any given opportunity. |
32 |
|
33 |
> > > In my proposal, I am addressing labels; will fold in your claims, |
34 |
> > > but those claims basically are shit- however, if you *did* find a |
35 |
> > > conflicting nested example that wasn't contrived, preferablly |
36 |
> > > multiple, I'd like those examples so I can include them into the |
37 |
> > > proposal (give labels a fair hand, basically). |
38 |
> > |
39 |
> > You already have an example in your proposal, in the form of |
40 |
> > mplayer's X? ( ) dependencies. |
41 |
> |
42 |
> I said nested conflicting labels. Meaning |
43 |
> "build: x? ( dar run: blah )" |
44 |
> |
45 |
> which isn't the case for any of mplayer deps. |
46 |
|
47 |
x? ( build: a run: b ) *is* nested "conflicting". |
48 |
|
49 |
You're still failing to understand the point of labels parsing rules, |
50 |
though: the point is to make uses like the above well defined and |
51 |
consistent. |
52 |
|
53 |
> We are not exherbo- we do not have the luxury of chucking out syntax |
54 |
> and pulling NIH renaming of things for shits and giggles. Especially |
55 |
> if the new syntax is directly translatable into a tweak of our |
56 |
> existing syntax (a tweak that we should do anyways- recall I built |
57 |
> this off of fixing USE_EXPAND). |
58 |
|
59 |
This isn't chucking out syntax. It's augmenting existing syntax. What |
60 |
you're doing is trying to shove something new onto an existing syntax |
61 |
which doesn't fit it. |
62 |
|
63 |
You should know this from REQUIRED_USE: that's a perfect example of |
64 |
going too far to reuse existing syntax. |
65 |
|
66 |
> Your argument boils down to "it's not labels, ignore that it's |
67 |
> aesthetic knob polishing (you can do the same w/ our existent |
68 |
> syntax, thus the analogy of waxing it I truly mean), use labels |
69 |
> because I'll berate you incessently till you accede". |
70 |
|
71 |
It's about giving ebuild developers a good format to work with. That |
72 |
sort of thing matters. There are a lot of ebuilds and not many package |
73 |
manglers. |
74 |
|
75 |
-- |
76 |
Ciaran McCreesh |