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 AFC5C138247 for ; Sat, 11 Jan 2014 11:53:48 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 93C1EE0C6D; Sat, 11 Jan 2014 11:53:42 +0000 (UTC) Received: from foo.stuge.se (foo.stuge.se [212.116.89.98]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 41C69E0B88 for ; Sat, 11 Jan 2014 11:53:40 +0000 (UTC) Received: (qmail 26340 invoked by uid 501); 11 Jan 2014 11:53:38 -0000 Message-ID: <20140111115338.26339.qmail@stuge.se> Date: Sat, 11 Jan 2014 12:53:38 +0100 From: Peter Stuge To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC: storing predefined INSTALL_MASK directory lists in repos Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <20140111112019.45f81ec6@gentoo.org> 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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="84ND8YJRMFlzkrP4" Content-Disposition: inline In-Reply-To: <20140111112019.45f81ec6@gentoo.org> X-Archives-Salt: d075aa0f-bd01-4fec-bb64-263d2f5d7f3a X-Archives-Hash: 1804a3bc2f63fc5c6bcd4017515e46c0 --84ND8YJRMFlzkrP4 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Micha=C5=82 G=C3=B3rny wrote: > INSTALL_MASK=3D"systemd bash-completion" >=20 > What are your thoughts? It seems like this will generally duplicate all -USE flags. Would it make sense to instead have a single setting which changes the meaning of USE to be that everything not USEd is install-masked? Rather than adding another distinct step into the pipeline, perhaps the trigger for doing the filtering can instead be integrated with an existing mechanism, to optimize for low complexity and high reuse? //Peter --84ND8YJRMFlzkrP4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFS0TDChR3Q0dhIfEgRAir2AJ0Ug7REMG4694mBEfmxS8aj0DCzngCfZVQp CyWbmqX2qkdBz+xJDWK2gdU= =nUc8 -----END PGP SIGNATURE----- --84ND8YJRMFlzkrP4--