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 D4FAE138010 for ; Tue, 18 Sep 2012 10:00:13 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6DC8621C0E4; Tue, 18 Sep 2012 09:59:29 +0000 (UTC) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 2FDA721C0A7 for ; Tue, 18 Sep 2012 09:58:24 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so11861493pbb.40 for ; Tue, 18 Sep 2012 02:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Lf23UwSKpib/jZBxmp/1Ig/r3oxQdJtFRiwbpPK3zBY=; b=qWQcQKraeQltEHXh0Mvitk2SDwv5GO39kEehR04ucyMP2LP41SEFWc4V7G64Fhft1c U1h+a9cXmEnhbW2pIK+Wey85wmQfA3iienx2EttpbrDKwVrCpjZw3VLGV26FRXYCSqRZ x2cyEhEyogbq36KSwWRz7Jp0VKg7vzVfSLfSaFaIjrPmUuMxMjwdAiVhi1QtC6AQcAXl GaYxe5m8R+yC4Q7K0AlfUxGQhD0BfEdkHWOFvxqeMkdVpAWkeBXLhTrdAssrIQuoxyDP fseyO3rYtDuUFeMGC8EhTrJgfb8YuyzGbZtLYAJrmpZMCKKbYjz8LF7pD3gVvuoM8Y0q Zx1g== Received: by 10.68.223.163 with SMTP id qv3mr326768pbc.101.1347962304533; Tue, 18 Sep 2012 02:58:24 -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 wn1sm8388999pbc.57.2012.09.18.02.58.22 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Sep 2012 02:58:23 -0700 (PDT) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Tue, 18 Sep 2012 02:58:35 -0700 Date: Tue, 18 Sep 2012 02:58:35 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal Message-ID: <20120918095835.GD5384@localhost> References: <20120916135211.GC23030@localhost> <201209180604.55067.Arfrever.FTA@gmail.com> 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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201209180604.55067.Arfrever.FTA@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 46e3192d-46f8-4158-8245-efad6deccf19 X-Archives-Hash: d02b99ddd7997ae62ea29055686552ab On Tue, Sep 18, 2012 at 06:04:51AM +0200, Arfrever Frehtes Taifersar Arahesis wrote: > A potential dev-libs/dep package I assume this is a hypothetical package; if this is something out of your personal eapi/repo, please state so. > might have valid use case for USE flags related to USE_EXPAND="DEP". > Your suggested syntax for types of dependencies in DEPENDENCIES would conflict with these USE flags > after implementing ":" delimiter for USE_EXPAND-related USE flags. Actually, that was both the intent, and I thought explicitly clear/documented; 'dep' would be a PM controlled namespace- as I'm pretty sure I stated in the doc, else in that email thread on the subject. Thus, yep, you got me, you can't create a USE_EXPAND/USE_GROUP named 'dep'. I very, very strongly doubt that anyone ever would come up with a scenario where this is required, and the alternative name is somehow worse. Please give examples. Also, you should keep in mind that w/ what I ultimately want for USE_EXPAND, we'd have a couple other namespace that couldn't be used by ebuilds/profiles. Top of the head, * arch; kind of a given, alternate addressing of x86 via arch:x86. Would be added purely for consistency, although iteration of the potential values would warrant the group existing. * use; same reasoning as arch, added for consistency so the consuming code doesn't have to special case things. * phase; intentionally reserved should we ever decide to do per phase restrict control (aka, turning userpriv off just for the test phase). * license; Now, this one I *am* spitballing a bit- I'm not proposing it, just frankly thinking out loud. If we had a license namespace there, we could potentially mask out certain deps if the user requested say pure bsd, or as a potential way to properly integrate in our existing bindist support; keep in mind if the group existed, we could use it in REQUIRED_USE also. Either way, you get the idea; it was explicit that in fixing use_expand, a few namespaces would be offlimits. > I vote for a separate syntax for types of dependencies. A separate syntax, or keeping dep:build? from conflicting w/ someone wanting to use USE_EXPAND="DEP" ? If you've got other critiques state them, else, while your opinion is yours, I doubt anyone is going to agree with you that it's a deal breaker. ~harring