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 6F5B9138010 for ; Mon, 1 Oct 2012 07:17:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9125A21C010; Mon, 1 Oct 2012 07:17:27 +0000 (UTC) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by pigeon.gentoo.org (Postfix) with ESMTP id BE5C921C003; Mon, 1 Oct 2012 07:16:39 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id ds1so1143952wgb.4 for ; Mon, 01 Oct 2012 00:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=TZ2AF1qs1rRfCrsVFfYWgU6FzWDaZ8hbfEzf1KcZml8=; b=0g3Y+prp+qPy5Pe9qxeU0LM2QrOfURQDh2c3vjF2KHRdIyFU+09ZgniGt6p9JoR/D3 hXy8lEWnjZwR/zWXJGtxp8t3XsEc9LifjtXzePKM1O18aoEhrwum2TFJ7EKLvviH2QZx 2QDEiBhJUR/9WzMgEe0B+KwWX9Clfo059fBmb1TQlPq/+IRDi6dPUE4jwQre+JJ87Hbx NF5K97a8nsbaYbGzcCt30gFhFfbnM3QMtqYIb7MD1Ahig0C1H+ZdPa7fv+GC3/tWscyZ vfusKMQoAPmcqiLp0oRNZJm3gg8MfRBjDLZqJDTVOxZBWF+Dlk6WV1gfP/vbYDDxi5Is S9dA== Received: by 10.216.209.150 with SMTP id s22mr7499318weo.49.1349075798927; Mon, 01 Oct 2012 00:16:38 -0700 (PDT) Received: from localhost (cpc13-broo7-2-0-cust130.14-2.cable.virginmedia.com. [82.9.16.131]) by mx.google.com with ESMTPS id ct3sm15114192wib.5.2012.10.01.00.16.37 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Oct 2012 00:16:38 -0700 (PDT) Date: Mon, 1 Oct 2012 08:13:49 +0100 From: Ciaran McCreesh To: Brian Harring Cc: gentoo-pms@lists.gentoo.org, gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal Message-ID: <20121001081349.59ba2745@googlemail.com> In-Reply-To: <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> <20120930235656.GA10800@localhost> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.11; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/Uq0ermcxwS+4shJ_rcODPVs"; protocol="application/pgp-signature" X-Archives-Salt: 86939a9b-eaf7-4c85-bebd-ccf3356ced7f X-Archives-Hash: 7b773bbace8dacfc7b69c167742a529a --Sig_/Uq0ermcxwS+4shJ_rcODPVs Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 30 Sep 2012 16:56:56 -0700 Brian Harring wrote: > 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. >=20 > No, when I say pragmatic, what I'm actually saying is that people who=20 > can't focus on cost/gain, by large, haven't had real jobs (else they=20 > would've had that perfectionism/decreasing gains ground out of them=20 > sooner or later), and are spending their time whacking off chasing a=20 > mythical 'perfect' solution. I don't know whether you're aware of this, but a small number (cost per ebuild) multiplied by a big number (lots of ebuilds) can be larger than a medium sized number (cost of implementing a good solution). I realise this is a sophisticated technique I'm using here, but I assure you multiplication has been used in some industries for a few years now. > Academic wankery, is the short version. You're good at technical, > but you frequently do the academic wanking crap which leads to things=20 > dead-ending... plus wasted time because to you, 'pragmatic' is a > dirty word (compromise? Heaven forbid!). Or looking at it another way: you're so eager to deliver a "compromise" and a "pragmatic" solution (at the expense of ebuild writers everywhere) that you immediately rule out a "good" solution just so you can push the virtues of doing it wrong. Doing it wrong should be a last resort, not something you look to do at any given opportunity. > > > In my proposal, I am addressing labels; will fold in your claims, > > > but those claims basically are shit- however, if you *did* find a=20 > > > conflicting nested example that wasn't contrived, preferablly=20 > > > multiple, I'd like those examples so I can include them into the=20 > > > proposal (give labels a fair hand, basically). > >=20 > > You already have an example in your proposal, in the form of > > mplayer's X? ( ) dependencies. >=20 > I said nested conflicting labels. Meaning=20 > "build: x? ( dar run: blah )" >=20 > which isn't the case for any of mplayer deps. x? ( build: a run: b ) *is* nested "conflicting". You're still failing to understand the point of labels parsing rules, though: the point is to make uses like the above well defined and consistent. > We are not exherbo- we do not have the luxury of chucking out syntax=20 > and pulling NIH renaming of things for shits and giggles. Especially=20 > if the new syntax is directly translatable into a tweak of our=20 > existing syntax (a tweak that we should do anyways- recall I built=20 > this off of fixing USE_EXPAND). This isn't chucking out syntax. It's augmenting existing syntax. What you're doing is trying to shove something new onto an existing syntax which doesn't fit it. You should know this from REQUIRED_USE: that's a perfect example of going too far to reuse existing syntax. > Your argument boils down to "it's not labels, ignore that it's=20 > aesthetic knob polishing (you can do the same w/ our existent=20 > syntax, thus the analogy of waxing it I truly mean), use labels=20 > because I'll berate you incessently till you accede". It's about giving ebuild developers a good format to work with. That sort of thing matters. There are a lot of ebuilds and not many package manglers. --=20 Ciaran McCreesh --Sig_/Uq0ermcxwS+4shJ_rcODPVs Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlBpQrUACgkQ96zL6DUtXhE9HgCghS2RdAc80n8+l8c/g++xc5S8 vnQAoNRMAIV4JPGfKjK50xmdVJar1azW =Da2H -----END PGP SIGNATURE----- --Sig_/Uq0ermcxwS+4shJ_rcODPVs--