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 09D3B138010 for ; Sun, 30 Sep 2012 20:36:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DF0CAE0574; Sun, 30 Sep 2012 20:35:48 +0000 (UTC) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 36EBFE0566; Sun, 30 Sep 2012 20:35:47 +0000 (UTC) Received: by weyu54 with SMTP id u54so2616698wey.40 for ; Sun, 30 Sep 2012 13:35:47 -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=VkltezQwGxrvQbMJ/mZpVLllO1dIEq/CMqwd34EL37A=; b=1GPlnVhBVqt+d3GWwrbux34qqBnZ4/ctwzYxA3DwSE0ozbmo4CC3GLI4FJPyq0xuoA NxZKapWRZAfvM1ezy3/WXpkbLzserlqdf7sTnB3z+DeYuNq3cUCjPFotpy+ZYRoJcFEq SPg2bU3pp/vBoiW7peukCv+gDDGlQiYls/S7/ozbgBHF+n/cg6tt5EeNoi1aFQkWOIMg 5hNieiszydrhV1Us8/qRUIj248dmBDMkrH9Y813vDSyozJ9vEXE5qsh8o3zVCvdFLA+g zPExpq7hvw36XS/LHd7DB0nZatJ8bVdIoLWNOYue9ci50ZZ/2apwIw9VWuYNdKwSwj7Y x4WA== Received: by 10.180.8.40 with SMTP id o8mr10032271wia.9.1349037347402; Sun, 30 Sep 2012 13:35:47 -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 k2sm14442668wiz.7.2012.09.30.13.35.45 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 30 Sep 2012 13:35:46 -0700 (PDT) Date: Sun, 30 Sep 2012 21:30:18 +0100 From: Ciaran McCreesh To: Brian Harring Cc: gentoo-pms@lists.gentoo.org, gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal Message-ID: <20120930213018.22fe16f3@googlemail.com> In-Reply-To: <20120930201453.GC2180@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> 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 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: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/sRXuwH5rmY5l/HC.QZX5W+v"; protocol="application/pgp-signature" X-Archives-Salt: 80925b00-2087-4f95-93be-27d4deb21b21 X-Archives-Hash: 83ed27a718382262f26f7a62eb706460 --Sig_/sRXuwH5rmY5l/HC.QZX5W+v Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 30 Sep 2012 13:14:53 -0700 Brian Harring wrote: > > That's largely because there are a lot of former Gentoo developers > > there who all said "oh, yeah, I forgot we could do it the other way" > > when this was pointed out... >=20 > I analyzed *all* exheres on git.exherbo. >=20 > To be crystal clear, these include your packages. >=20 > You yourself didn't use nested labels. So either the author of > labels 'forgot' he could use it, or just didn't find the nesting > actually useful. That's a rather disingenuous claim, considering how none of the packages I maintain have any non-trivial dependencies... You could equally well say that every single package I maintain makes use of nested labels in every single place where they're relevant. > So... real world usage removes one of the core arguments of labels,=20 > leaving it just as "it's a new syntax/aesthetically more pleasing" in=20 > comparison to dep:build? ( blah ) form. >=20 > Not expecting you'll agree with that statement based on the facts of=20 > y'alls own repo... so if you're going to retort, bust out actual=20 > examples from eithe trees, where nesting would be preferable to the=20 > form people use now please; else just drop it (-your- own usage of=20 > labels disproves your claim; thus why I want actual examples now if=20 > that point will be debated any further). It's not just that it's more aesthetically pleasing. There are two arguments favouring labels over use abuse. The first is that it doesn't have perverse behaviour associated with it like your misappropriation of use conditionals does. If you put labels deep in a tree, it's well defined. If you put your conditionals anywhere except the top level, crazy stuff happens. The second is that it starts the conceptual shift from "cat/pkg is a build dep, and cat/pkg is a run dep" to "cat/pkg is a dep that is required for build and run". > Bluntly, you want something that is academically possible, but=20 > pragmatically/realistically unneeded- meaning the gains are basically=20 > not there, but the costs most definitely are. No, I want something where things that are different look different. Dependency types are nothing like use flags, so they shouldn't look the same. > Either way, this is gentoo, we're talking about the ebuild format;=20 > just the same as everyone shredded mgorny's ass for proposing we=20 > mangle atom syntax w/out gain, and proposal you push for the deptree=20 > changing, has to have significant gains for changing the existing=20 > form; aesthetics at a cost aren't enough. The gain is that you have a syntax designed for what's being represented, not an existing syntax abused to sort of (but not quite, because it's still defined in terms of rendering down) do new things. Really, all it takes to see that your syntax is bad is one tiny little example: dep:build? ( dep:run? ( cat/pkg ) ) There shouldn't be any need to add in a repoman check to catch that kind of thing. The problem is entirely caused by bad syntax design. Implementing labels is not difficult, and the extra cost is worth it to get a good design. --=20 Ciaran McCreesh --Sig_/sRXuwH5rmY5l/HC.QZX5W+v Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlBoq90ACgkQ96zL6DUtXhFfzwCbBEspnv7K+ctgqfM78ltYW9/T u6kAnjCrBCmTrF981mE2MijPPXF5oy++ =W9ox -----END PGP SIGNATURE----- --Sig_/sRXuwH5rmY5l/HC.QZX5W+v--