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 1SsGFf-0007R0-Iz for garchives@archives.gentoo.org; Fri, 20 Jul 2012 16:40:27 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EC16821C001; Fri, 20 Jul 2012 16:40:07 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 6DCCBE0230 for ; Fri, 20 Jul 2012 16:39:24 +0000 (UTC) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: floppym) by smtp.gentoo.org (Postfix) with ESMTPSA id A54C61B4018 for ; Fri, 20 Jul 2012 16:39:23 +0000 (UTC) Received: by wgbfm10 with SMTP id fm10so3197669wgb.10 for ; Fri, 20 Jul 2012 09:39:21 -0700 (PDT) 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 Received: by 10.180.103.4 with SMTP id fs4mr15987573wib.16.1342802361266; Fri, 20 Jul 2012 09:39:21 -0700 (PDT) Received: by 10.223.3.142 with HTTP; Fri, 20 Jul 2012 09:39:21 -0700 (PDT) In-Reply-To: <20120720075457.4cccea26@googlemail.com> References: <20120719151422.1fb9883b@sera-17.lan> <50087884.90006@gentoo.org> <20120720075457.4cccea26@googlemail.com> Date: Fri, 20 Jul 2012 12:39:21 -0400 Message-ID: Subject: Re: [gentoo-dev] RFC: l10n.eclass From: Mike Gilbert To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 25685edb-a52f-4d5e-bb6c-1e4493c5f017 X-Archives-Hash: 3a8c12e6d63f7a81650c1ad075059dbe On Fri, Jul 20, 2012 at 2:54 AM, Ciaran McCreesh wrote: > On Thu, 19 Jul 2012 18:34:41 -0400 > Mike Gilbert wrote: >> On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico >> wrote: >> > On 07/19/2012 06:14 AM, Ralph Sennhauser wrote: >> >> Could be that Portage re-exports a sanitized >> >> LINGUAS tough, but I doubt it. >> > >> > Portage does sanitize it if there are any linguas_* flags in IUSE, >> > otherwise it lets the variable pass through without sanitizing it. >> >> That's good; we definitely don't want to "sanitize" it if there are no >> linuguas_* flags in IUSE. This would break LINUGUAS support for many >> autotools/gettext based packages, where the autotools code parses >> LINGUAS directly and the ebuild does nothing with it. > > If there aren't any linguas_* flags in IUSE, LINGUAS should be empty, > and will be in future EAPIs. Without that, USE dependencies on > USE_EXPAND variables don't work. How do you figure that? The current portage behavior works well enough; if linugas_* is in IUSE, LINGUAS is treated as a USE_EXPAND, and use-deps should work fine. Otherwise, it is treated just like a normal environment variable, and portage doesn't touch it. For most gettext packages, there is absolutely no reason that the ebuild maintainer should have to keep track of every translation available in a given package across version bumps. If you change this behavior in a future EAPI, you will break this.