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.60) (envelope-from ) id 1OMQqu-0005Ek-Dl for garchives@archives.gentoo.org; Wed, 09 Jun 2010 19:22:16 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 896E7E0982; Wed, 9 Jun 2010 19:22:12 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 887DDE0971 for ; Wed, 9 Jun 2010 19:21:51 +0000 (UTC) Received: from gentoo.org (cp1107341-a.dbsch1.nb.home.nl [84.31.115.1]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 86C1F1B40E6 for ; Wed, 9 Jun 2010 19:21:50 +0000 (UTC) Date: Wed, 9 Jun 2010 21:21:44 +0200 From: Harald van =?utf-8?Q?D=C4=B3k?= To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] LINGUAS handling Message-ID: <20100609192121.GA16981@boostbox> References: <1276069107.16507.475.camel@tablet> 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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1276069107.16507.475.camel@tablet> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: 8f911924-582d-4bd9-b7b9-cc749bc6bc9e X-Archives-Hash: 643dc4695e0ff4348677718c94f90587 On Wed, Jun 09, 2010 at 11:38:03AM +0400, Peter Volkov wrote: > 1. Do we want all packages to support LINGUAS if possible? It is > possible to leave gettext based package without LINGUAS and everything > will just work, but I think that it's good idea to make supported > languages visible to user through linguas_ flags. I agree, but I'd like to point out this would be a visible change in default behaviour: the default would change from "install everything" to "install nothing". For gettext-based packages, "install everything" is a sane default, in my opinion. > 2. How should we handle case of unset LINGUAS in ebuild? Should we mimic > gettext and install all supported languages, using code like > > LINGUAS=${LINGUAS-%UNSET%} > if test "%UNSET%" == "$LINGUAS"; then > # install all supported languages > fi Firstly, don't use == with test. It's not portable. The bash built-in test supports ==. Other test implementations don't, such as the one from GNU coreutils, and the built-in test in other shells, don't. If you use test in a context where you're absolutely sure the built-in version will be used, and the executing shell is bash, then I suppose you can use ==, but at that point you're better off using [[ ]] anyway. That said, to test if a variable is set, use ${VAR+set} over ${VAR-unset}. ${VAR-unset} evaluates to "unset" if VAR is unset, and if VAR is set to the string "unset". I suppose that's why you used %UNSET%, to reduce the possibility of accidents. You can reduce it to 0, using for example if [[ -z ${LINGUAS+set} ]]; then # LINGUAS is unset fi > ? If yes, it's easy to write such code and put in eclass. If no, how do > we live with inconsistency that some packages will install all languages > some, will install nothing (document in handbook and add portage warning > in case LINGUAS is unset?)? Unfortunately, consistency either way is bad. Making unset LINGUAS install nothing changes gettext's design, when the whole idea behind LINGUAS was to mimic gettext's design. Making unset LINGUAS install everything causes massive disk space requirements for the default settings for some packages such as openoffice. In my opinion, either of those would be worse than having LINGUAS behave inconsistently. > 3. What is the purpose of strip-linguas function (mentioned in > devmanual)? It's clear what it does but I have no ideas why. Probably > similar code could be used in QA function that will gather supported > languages from po directories and warn maintainer that it's time to > update linguas_ in IUSE (and probably later it could be expanded > to support qt packages too). It's used for some packages that fail to build with certain LINGUAS values. If I recall correctly, binutils had a bug where putting en_GB in your LINGUAS made the build fail, for example. binutils doesn't support en_GB anyway, so it gets filtered out,