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 F1CE71381F3 for ; Mon, 29 Apr 2013 13:43:15 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6C28BE0972; Mon, 29 Apr 2013 13:43:09 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 861BCE096A for ; Mon, 29 Apr 2013 13:43:08 +0000 (UTC) Received: from marga.jer-c2.orkz.net (D4B2706A.static.ziggozakelijk.nl [212.178.112.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jer) by smtp.gentoo.org (Postfix) with ESMTPSA id 23F8233DED6 for ; Mon, 29 Apr 2013 13:43:06 +0000 (UTC) Date: Mon, 29 Apr 2013 15:43:03 +0200 From: Jeroen Roovers To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC: cartesian product extension to keyword system Message-ID: <20130429154303.52b66c5b@marga.jer-c2.orkz.net> In-Reply-To: <87ppxdajv8.fsf@proton.in.awa.tohoku.ac.jp> References: <87ppxdajv8.fsf@proton.in.awa.tohoku.ac.jp> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; i686-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: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 187c825f-f5f3-4d0a-8b7a-509fab6fd56a X-Archives-Hash: 0094f38935739d036fd79dd14e37c7bf On Mon, 29 Apr 2013 16:14:51 +0900 heroxbd wrote: > KEYWORDS="~hppa-hpux ~m68k-mint ~ppc-aix ~x64-solaris ~x86-interix["] > > KEYWORDS_ARCH="~alpha ~amd64 ~arm ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 > ~s390 ~sh ~sparc ~x86" Regardless of your chance of success in making the extra complexity manageable, I think moving the tradition KEYWORDS value to KEYWORDS_ARCH, and reusing KEYWORDS for something else , would needlessly increase the work required to "migrate" the portage tree. Why not leave KEYWORDS what it is right now, and expand/change its meaning using alternate variables so that you can (indefinitely) maintain backward compatibility? jer