public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Harald van Dijk" <truedfx@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] LINGUAS handling
Date: Wed, 9 Jun 2010 21:21:44 +0200	[thread overview]
Message-ID: <20100609192121.GA16981@boostbox> (raw)
In-Reply-To: <1276069107.16507.475.camel@tablet>

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_<lang> 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_<lang> 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,



  reply	other threads:[~2010-06-09 19:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-09  7:38 [gentoo-dev] LINGUAS handling Peter Volkov
2010-06-09 19:21 ` Harald van Dijk [this message]
2010-06-09 22:08   ` [gentoo-dev] " Duncan
2010-06-11  4:58   ` [gentoo-dev] " Peter Volkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100609192121.GA16981@boostbox \
    --to=truedfx@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox