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,
