From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id C4AC7138010 for ; Mon, 1 Oct 2012 00:10:47 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5D7FF21C0A5 for ; Mon, 1 Oct 2012 00:10:47 +0000 (UTC) Received: from mail-da0-f53.google.com (mail-da0-f53.google.com [209.85.210.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 9D57821C03A; Sun, 30 Sep 2012 23:56:59 +0000 (UTC) Received: by dadg9 with SMTP id g9so1650370dad.40 for ; Sun, 30 Sep 2012 16:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=kHzpORgErZsQKVzF8CT37z/KCVV/OkSgFc8RZZk+HDk=; b=ZBvibhjgOFGi/+lq9z75uNWFfbyOp7iT8s13TKUqGFAoE1T7PVaoqHCcr4+qwo/SJZ eflQg7hhxrew07rI0vJw2NvPl6bonaUdqp07EWe5dZUn4zze9o0FbpbaRsKBdKfY/qTJ LiAmFCBBThyeAsOsH6eU0kgDD+X5nogKvfFA6JKNxr8kHvKhheaTQoYgweX4kPYtdSwW bpZt1/bJlh/qITgcigRuxt/+yLhH64yc8A4Gjdb7mGosZlI7fnBSxvZCgiXMwVOtasaR ANytpIE/jo1Svf8hebKmIVbJe+GH9HQoczCIpaOyNF29KXe6FDnRfKLToqr66DFlmVpD /Bbw== Received: by 10.66.72.134 with SMTP id d6mr32632883pav.13.1349049418823; Sun, 30 Sep 2012 16:56:58 -0700 (PDT) Received: from smtp.gmail.com:587 (74-95-192-101-SFBA.hfc.comcastbusiness.net. [74.95.192.101]) by mx.google.com with ESMTPS id bj7sm9382618pab.24.2012.09.30.16.56.56 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 30 Sep 2012 16:56:58 -0700 (PDT) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Sun, 30 Sep 2012 16:56:56 -0700 Date: Sun, 30 Sep 2012 16:56:56 -0700 From: Brian Harring To: Ciaran McCreesh Cc: gentoo-pms@lists.gentoo.org, gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal Message-ID: <20120930235656.GA10800@localhost> References: <20120916135211.GC23030@localhost> <20120916153949.05ab795a@googlemail.com> <20120916160528.GD23030@localhost> <20120916175921.4f01661a@googlemail.com> <20120925224614.GF26094@localhost> <20120929170509.63efef70@googlemail.com> <20120930201453.GC2180@localhost> <20120930213018.22fe16f3@googlemail.com> <20120930214214.GE2180@localhost> <20120930225340.126b1027@googlemail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Package Manager Specification discussions X-BeenThere: gentoo-pms@gentoo.org X-BeenThere: gentoo-pms@lists.gentoo.org Reply-To: gentoo-pms@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120930225340.126b1027@googlemail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: ff92f042-c90e-469a-9b6c-c344e3c3c1d6 X-Archives-Hash: 3203eb4ea6218e2f962fa9a6a7cfd153 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