On Sun, Sep 30, 2012 at 10:53:40PM +0100, Ciaran McCreesh wrote: > But here's the thing: when you sell something as "pragmatic", what > you're really saying is "it's wrong, I know it's wrong, and I'm going > to pretend that wrong is a good thing". Getting it wrong should be > something you do only after you're sure you can't afford get it right; > it shouldn't be something you're proud of.
No, when I say pragmatic, what I'm actually saying is that people who can't focus on cost/gain, by large, haven't had real jobs (else they would've had that perfectionism/decreasing gains ground out of them sooner or later), and are spending their time whacking off chasing a mythical 'perfect' solution. Academic wankery, is the short version. You're good at technical, but you frequently do the academic wanking crap which leads to things dead-ending... plus wasted time because to you, 'pragmatic' is a dirty word (compromise? Heaven forbid!). > > In my proposal, I am addressing labels; will fold in your claims, but > > those claims basically are shit- however, if you *did* find a > > conflicting nested example that wasn't contrived, preferablly > > multiple, I'd like those examples so I can include them into the > > proposal (give labels a fair hand, basically). > > You already have an example in your proposal, in the form of mplayer's > X? ( ) dependencies. I said nested conflicting labels. Meaning "build: x? ( dar run: blah )" which isn't the case for any of mplayer deps. Actual examples from the tree where a conflicting nested label is preferable. That isn't one of 'em, and you're unwillingness/inability to point out real world examples is just digging a deeper ditch for your argument. > But that's missing the point. Even if you pretend complicated > dependencies don't exist, labels are still by far the better proposal. > Your argument boils down to "it's more pragmatic to do a quick and dirty > implementation in Portage and thus force the technical debt onto every > single ebuild than it is to do it cleanly". My argument boils down to thus: We are not exherbo- we do not have the luxury of chucking out syntax and pulling NIH renaming of things for shits and giggles. Especially if the new syntax is directly translatable into a tweak of our existing syntax (a tweak that we should do anyways- recall I built this off of fixing USE_EXPAND). Your argument boils down to "it's not labels, ignore that it's aesthetic knob polishing (you can do the same w/ our existent syntax, thus the analogy of waxing it I truly mean), use labels because I'll berate you incessently till you accede". Beauty of open source, you want it, go do it. If in, what, 4 years? 3? You've not been able to get off your ass, write a proposal, hell, do a portage patch (you've *never* done portage patches of any worth, bluntly- I know this since in the past I used to fix shit you requested), you lose your voice in the matter. Considering your points boil down to aesthetic academic wanking at this point... put up, or shut up, really is that simple. As said, you come up w/ real world examples, I'll include them; else persist and I'll just fold the academic wankery description of labels into the glep if you'd truly like me to (or you piss me off enough I do so to be a dick). ~harring
