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 C110B138010 for ; Sat, 29 Sep 2012 16:08:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B7C69E04D6; Sat, 29 Sep 2012 16:07:55 +0000 (UTC) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 974AFE0462; Sat, 29 Sep 2012 16:07:54 +0000 (UTC) Received: by wibhq12 with SMTP id hq12so713492wib.10 for ; Sat, 29 Sep 2012 09:07:53 -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=k6Gi3pGFnX5r+GWLeR7f36qNWd3fx2oRW8NJ9c0Tj6Y=; b=H2bPhOwqaZo13V7fIuF5M1K0d5NMT8nS19C/CW4qIwKyShk6xby6CA7i0FT75caNUL lzXAk5Woad/WZU4Oien2bJtWgnH578Pins3fiQjXXYooWNeKPk5GWhrFaQNUn4oY+4/d 9qY73pg1t3wxVMFr2KyU0u6zcKvZj+UijldrfP4J8wy6WwawcpkDhpXO/j8+//dZJxjU kHKo0fSBmmixCSR+qrnE0diK7dgWdnRF/vhzUCD/zm/LBpI/018xTHkDBP9sgkEs/m9n 80c6xsS7GgU8eeEIp9vYM4QafdquN1gBczeq/y7E0qfCqVJt96V41SU5/7M+eVKCUQEi JrBw== Received: by 10.180.96.164 with SMTP id dt4mr4288652wib.10.1348934873702; Sat, 29 Sep 2012 09:07:53 -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 k20sm5778632wiv.11.2012.09.29.09.07.52 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 29 Sep 2012 09:07:53 -0700 (PDT) Date: Sat, 29 Sep 2012 17:05:09 +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: <20120929170509.63efef70@googlemail.com> In-Reply-To: <20120925224614.GF26094@localhost> References: <20120916135211.GC23030@localhost> <20120916153949.05ab795a@googlemail.com> <20120916160528.GD23030@localhost> <20120916175921.4f01661a@googlemail.com> <20120925224614.GF26094@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_/i/qogNCtu1a6hWEBuQRNDTJ"; protocol="application/pgp-signature" X-Archives-Salt: 32d49acc-3a48-414c-928b-bace97d691bf X-Archives-Hash: 36fd9bde7e34eb7be2f419a29e9a2b0d --Sig_/i/qogNCtu1a6hWEBuQRNDTJ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 25 Sep 2012 15:46:14 -0700 Brian Harring wrote: > Fun fact; peoples usage of labels in exherbo is thus: >=20 > build+run: > set of deps > run: > set of deps/conditionals/etc 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... > > Specification in terms of rendering has a huge problem, though. > > Remembering the crazy rules Gentoo has for || ( flag? ( ) ), what > > does this do? > >=20 > > || ( dep:build? ( a ) dep:run? ( b ) ) >=20 > Honestly, I was waiting for you to bring this up :) >=20 > You're conflating two different things here; > 1) someone being a dumb ass and writing what's effectively a || (=20 > atom) block, just doing so in a manner w/out any reason to do so. >=20 > 2) Your ongoing jihad against || (), specifically the occasionally=20 > valid complaint that build/rdepend different means the resolver can=20 > get stuck in certain pathways when slots are involved, abi, etc. >=20 > Either way, in my proposal, I'm not going to single that out and try=20 > blocking it. The rendered version of it is still stable, albeit if=20 > it's build/run it's unlikely to be desired if there is ABI involved=20 > (for non ABI, specifically self-bootstrapping codebases, I suspect=20 > someone could come up with a valid construct- sed has something=20 > similar if memory serves). The rendered version ends up as ( a b ), in effect... It doesn't end up as || ( a (at build time) b (at runtime) ). > Which is stupid, but syntactically correct. Nor is this a new issue,=20 > thus I don't particularly agree with your approach of trying to sink=20 > the proposal via an orthogonal problem. No, you're introducing a new kind of weirdness for || ( ) here. > Either way, via=20 > http://dev.gentoo.org/~ferringb/unified-dependencies/labels/translated-to= -use-deps.txt=20 > , I think it's pretty clear labels in real world usage aren't > bringing anything to the tabel that we wouldn't have via my proposal; > that leaves labels as just a different syntax (perhaps aesthetically > more pleasing at first glance, but the label stacking bit via exheres=20 > analysis is proven to be something people explicitly go out of their=20 > way to protect against; meaning the aesthetics have a mental=20 > model cost). It's not "go out of their way to protect against". It's "there's an easy way of making sure everything is composable". Your misappropriation of use flags doesn't have that. --=20 Ciaran McCreesh --Sig_/i/qogNCtu1a6hWEBuQRNDTJ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlBnHDkACgkQ96zL6DUtXhG+hwCgh+bz7XYfih8IYfgrwgM/E/bd JAEAnj4EtvGMmsccUOzSvoC8/Oei34EE =2IJy -----END PGP SIGNATURE----- --Sig_/i/qogNCtu1a6hWEBuQRNDTJ--