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 6AB29138010 for ; Thu, 13 Sep 2012 17:57:18 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C882D21C0BE; Thu, 13 Sep 2012 17:56:14 +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 D3E0221C0A1 for ; Thu, 13 Sep 2012 17:53:38 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so4625527pbb.40 for ; Thu, 13 Sep 2012 10:53:38 -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=ctg1HOtDOf+aRw2HbCAle59yqEX0VPpRA1ZdGanEdKE=; b=TAza3V7a3wa9b1k3ZwlYyu8gqR6Rv88KGtajnZ5tENglSCEcMnJjT79EReCKDz8oTN v45ZhT5zUWIXDO4xhXQ0vhEYJgeChm+vCOCbStOHq8y2nUzOMmSUDMWKS2WbDbGt+AP4 4S6ED69OV5HVBqDBOLVpE2wOx+n9OtipKKABz60E4cijjHhO+i0xfPyvjvLbXnCGTpst oHTqM2SYSp/e7+c0z24maqJbJRR1Gg8ylS+hFzASbzn1h8PT6Xsk/oQ4aa7m0wXh/+eM C1CHs84vMKkDtr0IFJES3uArc3wDA4QrRbsAdvfxou5E3bqnyG5zC5wMHE3IiS6022IS 18Ow== Received: by 10.66.87.132 with SMTP id ay4mr4121487pab.82.1347558818150; Thu, 13 Sep 2012 10:53:38 -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 pf10sm7248264pbc.56.2012.09.13.10.53.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Sep 2012 10:53:37 -0700 (PDT) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Thu, 13 Sep 2012 10:53:45 -0700 Date: Thu, 13 Sep 2012 10:53:45 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] USE_EXPAND / USE 'configuration space' refactoring: bikeshedding the separator Message-ID: <20120913175345.GD28593@localhost> References: <20120913103332.GC28593@localhost> <20120913162427.6cc0e4de@googlemail.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: <20120913162427.6cc0e4de@googlemail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 3ffd8af3-f9cf-4e92-a730-53214532d7b6 X-Archives-Hash: 2067eacdf36cd21d98709b178b00638c On Thu, Sep 13, 2012 at 04:24:27PM +0100, Ciaran McCreesh wrote: > On Thu, 13 Sep 2012 03:39:19 -0700 > Brian Harring wrote: > > 1) We disallow '@' in USE flags (yes, a use flag can actually have > > '@' in it's name according to PMS; someone was hitting the crack > > pipe pretty damn hard when they allowed that one). This doesn't > > impact anything in gentoo-x86, nor any tree I've ever seen. > > No crack pipe was involved in that decision! It's because of LINGUAS. > > (Incidentally, we used : rather than @ for separation for exheres-0 for > that reason.) Who says Linguas definition didn't involve a bit 'o crack? ;) On that subject, not entirely sure how the hell a grepp'ing of profiles on my part missed that file; worse, I distinctly recall this coming up in the past. Suspect it's time we add a footnote to that section of names since it's non-obvious. Sigh... Two angles; 1) Mind you, the woken up/caffeine ratio currently blows so this could be quite off kilter- but at first glance the '@' linguas usage actually seems to map to sub use groups (both in intent and grouping), at least for the quick scan I did of what we use. Might not actually be an issue, iow if we allow that, although that's assuming the '@' subgroup approach translates reasonably cleanly. The potential failure I'd see with that approach is it's a bit reliant on the assumption that the rules: `language[_territory[.codeset]][@modifier]` have been abided by- that the modifier is just that, a modifier. Were we to do this, which, at least at first sight, seems like a nifty solution that addresses it, we'd *likely* want sub groups to have a rule such that if you try to expand the subgroup of a setting, and that setting isn't a subgroup, it is considered 'on'. Basically, for the linguas case, it kind of sucks if we get into the situation where the consuming ebuilds/eclasses has to be sensitive to which modifiers were exposed. Essentially: linguas@de_DE@, if not a subgroup to expand to, is treated as scalar, rather than list. Impliciations of that I've not yet fully thought out- note that tweak isn't necessary for the basic notion of #1 to be usable also. 2) bikeshedding potentials: just spitballing a couple of potentials if '@' subgroups there doesn't fly for folks reading (mean it nicely, we shouldn't diverge arbitarily, but in the same instant we shouldn't import syntax/notions from exherbo unless they explicitly make sense in the gentoo/PMS context; the formats diverge enough the "reuse for compatibility" argument doesn't hold much water): ruby_targets@ruby_18 ruby_targets:ruby_18 ruby_targets|ruby_18 ruby_targets(ruby_18) Potentially fun thought, although the syntax is kind of ugly; basically we treat 'ruby_target' as a matching target (restriction in pkgcore vernacular, something that matches something else); the nice thing about this is it naturally plugins into the notion of multiple settings: ruby_targets[ruby18] ruby_targets[ruby18,ruby19] In the same angle, while it's partially valid bash (and not in the single setting case): ruby_targets{ruby_18} ruby_targets{ruby_18,ruby_19} That said, I consider the [] and {} syntax absolutely freaking ugly to the eye. I mention it should others think it's not butt-fugly. If approach #1 doesn't fly, using ':' as the delimiter gets my vote. ~harring