[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    [gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
From:       Brian Harring <ferringb () gmail ! com>
Date:       2012-09-30 23:56:56
Message-ID: 20120930235656.GA10800 () localhost
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]