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 1SsH1y-0007bn-42 for garchives@archives.gentoo.org; Fri, 20 Jul 2012 17:30:22 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 56961E073F; Fri, 20 Jul 2012 17:30:07 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id A3156E055E for ; Fri, 20 Jul 2012 17:29:27 +0000 (UTC) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (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 D5CBF1B4018 for ; Fri, 20 Jul 2012 17:29:26 +0000 (UTC) Received: by weyt57 with SMTP id t57so3009279wey.40 for ; Fri, 20 Jul 2012 10:29:24 -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.78.35 with SMTP id y3mr27916105wiw.16.1342805364469; Fri, 20 Jul 2012 10:29:24 -0700 (PDT) Received: by 10.223.3.142 with HTTP; Fri, 20 Jul 2012 10:29:24 -0700 (PDT) In-Reply-To: <20120720180910.748470a0@googlemail.com> References: <20120719151422.1fb9883b@sera-17.lan> <50087884.90006@gentoo.org> <20120720075457.4cccea26@googlemail.com> <20120720180910.748470a0@googlemail.com> Date: Fri, 20 Jul 2012 13:29:24 -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: 0a359a77-e0cd-4e9e-a56c-cb4b14a6157f X-Archives-Hash: 704b124433159189202325c6a4e85d6d On Fri, Jul 20, 2012 at 1:09 PM, Ciaran McCreesh wrote: > On Fri, 20 Jul 2012 12:39:21 -0400 > Mike Gilbert wrote: >> 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? > > If you dep upon foo[linguas_en(+)] and linguas_en isn't in IUSE, what > happens? > Firstly, if there are no linugas_ flags in IUSE, I can't see any point in such a dependency. Given the current behavior, I believe the dependency would always satisfied due to the (+). That seems fine to me. >> 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. > > It's not a normal environment variable, and it never has been. > It was a normal variable before someone added it to USE_EXPAND. From cvs, it looks like that happened in 2005 or so. >> 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. > > Don't use a USE_EXPAND variable if you don't want USE_EXPAND behaviour. > I beleive LINGUAS originates from the autoconf macros (po.m4) provided by the gettext package. I believe we added it to USE_EXPAND some time after it was implemented in gettext. This "just works" given the current portage behavior. Perhaps we need to provide a cleaner way for ebuilds to specify if a given variable should be treated as a USE_EXPAND or not.