From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.77) (envelope-from ) id 1SsIgn-0000p0-GL for garchives@archives.gentoo.org; Fri, 20 Jul 2012 19:16:39 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8AE4DE07E6; Fri, 20 Jul 2012 19:16:24 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 4A89EE07B5 for ; Fri, 20 Jul 2012 19:15:36 +0000 (UTC) Received: from [192.168.1.43] (unknown [96.231.195.182]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: tetromino) by smtp.gentoo.org (Postfix) with ESMTPSA id 158091B4018 for ; Fri, 20 Jul 2012 19:15:34 +0000 (UTC) Message-ID: <1342811731.9434.70.camel@rook> Subject: Re: [gentoo-dev] RFC: l10n.eclass From: Alexandre Rostovtsev To: gentoo-dev@lists.gentoo.org Date: Fri, 20 Jul 2012 15:15:31 -0400 In-Reply-To: <20120720194134.61e917f2@googlemail.com> References: <20120719151422.1fb9883b@sera-17.lan> <50087884.90006@gentoo.org> <20120720075457.4cccea26@googlemail.com> <20120720180910.748470a0@googlemail.com> <1342806195.9434.24.camel@rook> <20120720185419.23244eb7@googlemail.com> <1342809439.9434.56.camel@rook> <20120720194134.61e917f2@googlemail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-k+X6y6te0JedKUJxsbn1" X-Mailer: Evolution 3.4.3 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 X-Archives-Salt: a3dcec61-36d0-4cd6-9b6b-0c58dce2fa61 X-Archives-Hash: ad5b28afd8b581099a023625aa87fe9d --=-k+X6y6te0JedKUJxsbn1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2012-07-20 at 19:41 +0100, Ciaran McCreesh wrote: > On Fri, 20 Jul 2012 14:37:19 -0400 > Alexandre Rostovtsev wrote: > > That suggests that the EAPI ought to define a second category of > > USE_EXPAND flags, one that has a different treatment of (+)/(-). > >=20 > > Something like the following: > >=20 > > A dependency on $foo[linguas_bar(+)] would be considered satisfied by > > an ebuild X matching $foo iff: > > 1. X has linguas_bar in IUSE and enabled; or > > 2. X does not have linguas_bar in IUSE, but there exists an ebuild Y > > (which may or may not equal X) matching $foo such that Y has at least > > one linguas_* flag in IUSE. >=20 > That's sensitive to old versions ebuilds being removed from the tree, so > it's utterly unworkable. I do not see why you think it's unworkable. Ebuilds already have dependencies that can be broken by removing an old version; if wombat depends on foo[bar], and you removed the only version of foo that had bar in IUSE, you broke wombat. Adding special LINGUAS handling would not change the fact that before deleting an ebuild, you need to verify that you did not render other ebuilds' dependencies unsatisfiable. --=-k+X6y6te0JedKUJxsbn1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAABAgAGBQJQCa5TAAoJEJ0WA1zPCt1hILUH/j8c1oyBKvv6TC0RWcWuvtFS qGLnT035n6/UPd9/wbCZpk156Dkl2OjK4Qq/IsDc9u4XOUxGOp2MB+KzUvc6ltyE mw7LnA9kqDpAH4RzM9lU3IUYgq/uPmITug8COL8kpAAZFxaqgMDX19TE6LwI1v2k qB+ZttiimHQWXogQxfls90mjsjB+zwgWA4rfjtUhEYJonM1ZJ6a/4MK5tJFdQg2/ 3y8Mt1f+/2YuwhvRk/XGsJezMQYOmvIzMZnRziadU7y6Z2c7ZLpOq2jFLvkEDexh AZqg4/bL/pv21tEdoEBCn6V1iejkxzF/qw4v1VsEv7WFcKx+kzF6Z3JFSj2EVSs= =tzKC -----END PGP SIGNATURE----- --=-k+X6y6te0JedKUJxsbn1--