1 |
On Wed, Jun 09, 2010 at 11:38:03AM +0400, Peter Volkov wrote: |
2 |
> 1. Do we want all packages to support LINGUAS if possible? It is |
3 |
> possible to leave gettext based package without LINGUAS and everything |
4 |
> will just work, but I think that it's good idea to make supported |
5 |
> languages visible to user through linguas_<lang> flags. |
6 |
|
7 |
I agree, but I'd like to point out this would be a visible change in |
8 |
default behaviour: the default would change from "install everything" to |
9 |
"install nothing". For gettext-based packages, "install everything" is a |
10 |
sane default, in my opinion. |
11 |
|
12 |
> 2. How should we handle case of unset LINGUAS in ebuild? Should we mimic |
13 |
> gettext and install all supported languages, using code like |
14 |
> |
15 |
> LINGUAS=${LINGUAS-%UNSET%} |
16 |
> if test "%UNSET%" == "$LINGUAS"; then |
17 |
> # install all supported languages |
18 |
> fi |
19 |
|
20 |
Firstly, don't use == with test. It's not portable. The bash built-in |
21 |
test supports ==. Other test implementations don't, such as the one from |
22 |
GNU coreutils, and the built-in test in other shells, don't. If you use |
23 |
test in a context where you're absolutely sure the built-in version will |
24 |
be used, and the executing shell is bash, then I suppose you can use ==, |
25 |
but at that point you're better off using [[ ]] anyway. |
26 |
|
27 |
That said, to test if a variable is set, use ${VAR+set} over |
28 |
${VAR-unset}. ${VAR-unset} evaluates to "unset" if VAR is unset, and if |
29 |
VAR is set to the string "unset". I suppose that's why you used %UNSET%, |
30 |
to reduce the possibility of accidents. You can reduce it to 0, using |
31 |
for example |
32 |
|
33 |
if [[ -z ${LINGUAS+set} ]]; then |
34 |
# LINGUAS is unset |
35 |
fi |
36 |
|
37 |
> ? If yes, it's easy to write such code and put in eclass. If no, how do |
38 |
> we live with inconsistency that some packages will install all languages |
39 |
> some, will install nothing (document in handbook and add portage warning |
40 |
> in case LINGUAS is unset?)? |
41 |
|
42 |
Unfortunately, consistency either way is bad. Making unset LINGUAS |
43 |
install nothing changes gettext's design, when the whole idea behind |
44 |
LINGUAS was to mimic gettext's design. Making unset LINGUAS install |
45 |
everything causes massive disk space requirements for the default |
46 |
settings for some packages such as openoffice. In my opinion, either of |
47 |
those would be worse than having LINGUAS behave inconsistently. |
48 |
|
49 |
> 3. What is the purpose of strip-linguas function (mentioned in |
50 |
> devmanual)? It's clear what it does but I have no ideas why. Probably |
51 |
> similar code could be used in QA function that will gather supported |
52 |
> languages from po directories and warn maintainer that it's time to |
53 |
> update linguas_<lang> in IUSE (and probably later it could be expanded |
54 |
> to support qt packages too). |
55 |
|
56 |
It's used for some packages that fail to build with certain LINGUAS |
57 |
values. If I recall correctly, binutils had a bug where putting en_GB in |
58 |
your LINGUAS made the build fail, for example. binutils doesn't support |
59 |
en_GB anyway, so it gets filtered out, |