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 1SsI5c-0002lt-BI for garchives@archives.gentoo.org; Fri, 20 Jul 2012 18:38:12 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AE07121C026; Fri, 20 Jul 2012 18:37:58 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 234D7E071D for ; Fri, 20 Jul 2012 18:37:22 +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 60FDA1B4003 for ; Fri, 20 Jul 2012 18:37:21 +0000 (UTC) Message-ID: <1342809439.9434.56.camel@rook> Subject: Re: [gentoo-dev] RFC: l10n.eclass From: Alexandre Rostovtsev To: gentoo-dev@lists.gentoo.org Date: Fri, 20 Jul 2012 14:37:19 -0400 In-Reply-To: <20120720185419.23244eb7@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> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-TxRfTO2iTbYF16dSPEHu" 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: 67e40448-5d25-4b9e-861c-ca383564bc3f X-Archives-Hash: c1d3df921fb100e6c3e80996ec39512e --=-TxRfTO2iTbYF16dSPEHu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2012-07-20 at 18:54 +0100, Ciaran McCreesh wrote: > On Fri, 20 Jul 2012 13:43:15 -0400 > Alexandre Rostovtsev wrote: > > > If you dep upon foo[linguas_en(+)] and linguas_en isn't in IUSE, > > > what happens? > >=20 > > Fatal error. If a package installs its translations implicitly via > > gettext's rules depending on the value of LINGUAS at configure time, > > then obviously other packages must rely on that package having > > installed any particular translation. >=20 > Uh, the entire point of the (+) is that it's *not* a fatal error if you > have a default. That suggests that the EAPI ought to define a second category of USE_EXPAND flags, one that has a different treatment of (+)/(-). Something like the following: 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. -Alexandre. --=-TxRfTO2iTbYF16dSPEHu 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) iQEcBAABAgAGBQJQCaVfAAoJEJ0WA1zPCt1h1EsH/A14NffmeGwea+4qxo0hAhYM qGvez9kBVfsMuvQTFd6XA1NQ8wr7nbKBVeYb7lCd92usgzX3CLuUKfaxStD/fvUD R5JUKtDyXTsrkw8nfG3fUNvZX28q3M4fFKoJEgdhQJEKkk5nXSEUAydaWsZvT3ed aPm4tNedUn/QE/xwihehloAmgoFQ8dfZQ0is+C7eb4kqMQZMcelEDtUvNnrm1Wpb 6Tt5CbwVkKSAfmiXFxb5ClIgDgkrJfNIr/t5Z1olfCrBIdv1Ht4lF+ykl3gsZ9jZ g6sXGO1DTpDUEzabGTzC+gK5wj4eCq1ds0p9+JUvJOOwEkbH1pfjjjJgPnkkqIQ= =flYB -----END PGP SIGNATURE----- --=-TxRfTO2iTbYF16dSPEHu--