1 |
Ühel kenal päeval, K, 01.06.2016 kell 20:24, kirjutas Martin Vaeth: |
2 |
> Gentoo has chosen this name so that as a side effect of setting |
3 |
> USE=linguas_* you also get a correct LINGUAS variable exported |
4 |
> (according to the USE-settings and your settings and according |
5 |
> to the ebuild's IUSE.) |
6 |
> These are the package with LINGUAS options in their USE flags |
7 |
> which you mentioned above. |
8 |
|
9 |
People already set LINGUAS for autotools control; using the same for |
10 |
USE_EXPAND probably seemed natural to re-use that, but the effects on |
11 |
PM variable mangling wasn't thought about at the time. |
12 |
This was introduced only to have a natural way to refer to them in |
13 |
SRC_URI and beyond, for extra language pack downloads (like firefox |
14 |
langpacks). |
15 |
Things escalated badly from there. |
16 |
|
17 |
> This had the advantage that no additional code except a correct |
18 |
> IUSE is needed for these ebuilds. (That's why gentoo has chosen |
19 |
> this name). |
20 |
|
21 |
> It had the disadvantage that: |
22 |
> 1. Ebuilds without handling IUSE=linguas_* explicitly (or |
23 |
> with wrong values, because maintainers did not care about the |
24 |
> values) had problems. |
25 |
|
26 |
There were no problems, and there still are no problem with implicit |
27 |
LINGUAS handling (by means of not listing them in IUSE), as long as the |
28 |
package manager doesn't modify the variable set in make.conf. |
29 |
The user has set it explicitly somewhere (make.conf most likely) and |
30 |
simply gets honored in upstream build system, just like CFLAGS. |
31 |
The problem is when package manager mangles it per PMS rules, for which |
32 |
I'm told portage has special PMS ignoring exceptions. |
33 |
|
34 |
> 2. Some packages which needed a different handling of LINGUAS |
35 |
> (like respecting the order) also had problems. |
36 |
|
37 |
LINGUAS does not imply any order whatsoever. Packages that assumed so |
38 |
were seriously buggy and if any still remain, this needs to be fixed |
39 |
ASAP. We have LC_* and LANG environment variables to choose what the |
40 |
localization is at runtime, not some arbitrary choice at build time. |
41 |
This is not a concern whatsoever, forget about it. |
42 |
|
43 |
> There are at least the following solutions to these disadvantages: |
44 |
> |
45 |
> a) |
46 |
> One _could_ solve problem 1 simply by not touching LINGUAS if |
47 |
> IUSE=linguas_* is not in the ebuild. (Main problem with this |
48 |
> solution: It is not PMS compatible; one needs e.g. |
49 |
> an exception for LINGUAS). |
50 |
|
51 |
This is a problem when they are in IUSE too. For example a package |
52 |
provides translations via gettext, but has extra downloads for some |
53 |
languages support (lets say grammar checking support for a language in |
54 |
an office application). The latter would get marked up with IUSE for |
55 |
usage in SRC_URI and install. Package manager will intersect them and |
56 |
remove the LINGUAS values not found in IUSE, but simple UI translation |
57 |
gettext catalogs for these languages might still exist upstream. They |
58 |
now get removed due to IUSE=linguas_* not including them. |
59 |
|
60 |
Including them all in IUSE for simple translation catalogs is not |
61 |
feasible to maintain. It also clutters emerge --verbose --pretend or -- |
62 |
ask output hard with LINGUAS="long list of 196 language codes" for |
63 |
these and mixes it all up for when the information is more useful when |
64 |
it implies huge extra downloads. |
65 |
|
66 |
And yes, there are packages that have 196 different language and |
67 |
dialects translations. Even core GNOME packages would have such an |
68 |
amount, see https://l10n.gnome.org/languages/ |
69 |
|
70 |
> In a similar manner, one could solve problem 2 by allowing |
71 |
> ebuilds to modify LINGUAS at build time (which is perhaps |
72 |
> also not PMS compatible). |
73 |
> |
74 |
> b) |
75 |
> Or one could, for all packages with LINGUAS in their USE-flag |
76 |
> simply rename IUSE=linguas_* to IUSE=l10n_* and set |
77 |
> export LINGUAS=$L10N |
78 |
> in these ebuilds (this would require practically no manual ebuild |
79 |
> editing if one does it in the l10n.eclass). |
80 |
|
81 |
The idea is not to export this anywhere in ebuilds. We'd have to do |
82 |
that in pretty much all. |
83 |
The point is that if the USE_EXPAND is renamed, then a LINGUAS as found |
84 |
in make.conf will just get passed verbatim into the environment (as |
85 |
parsed in via shlex - make.conf is not bash sourced), and then honored |
86 |
by upstream build system. |
87 |
That's because it isn't in USE_EXPAND list anymore, so it doesn't have |
88 |
such PMS rules to modify it. |
89 |
One can modify the environment via package.env as well, to change |
90 |
things per-package if one fancies for some reason. |
91 |
|
92 |
> I had originally understood mgorny's suggestion such that b) |
93 |
> is meant, and I would complain neither against a) nor b). |
94 |
> |
95 |
> But in his reply, mgorny says that, moreover, he wants to |
96 |
> remove the l10n.eclass, more precisely, that he considers |
97 |
> it as broken that packages use IUSE=l10n_* for setting |
98 |
> LINGUAS. |
99 |
> |
100 |
> This suggestion means that setting LINGUAS can be done |
101 |
> *only* in a hackish way by the user, "hidden" from the |
102 |
> package manager, not in the clean way as it is currently |
103 |
> done by those ebuilds with LINGUAS in their use-falgs. |
104 |
|
105 |
I don't see anything hackish in just setting L10N for extra language |
106 |
support downloads and LINGUAS for UI translations. |
107 |
|
108 |
> I agree with him that a hidden setting is a bad idea. |
109 |
|
110 |
You can find it in the VDB packed in environment.* in case of portage. |
111 |
Exporting it specially like CFLAGS, CXXFLAGS, FEATURES and others are, |
112 |
is a separate matter if one wants to propose that later. |
113 |
|
114 |
> Where our opinions strongly differ is whether a way to |
115 |
> cleanly set LINGUAS should be provided (e.g. by allowing |
116 |
> IUSE=l10n_* to modify LINGUAS appropriately, and make this |
117 |
> the "good" way instead calling it a "broken" way which |
118 |
> should be avoided.) |
119 |
|
120 |
I don't believe I have read such a claim from his e-mails anywhere, so |
121 |
not sure what this is about. |
122 |
|
123 |
> The INSTALL_MASK is an independent thing which for _many_ |
124 |
> packages "by accident" can be used with a similar effect as |
125 |
> setting LINGUAS (because many packages use LINGUAS only to |
126 |
> determine the files which they install). |
127 |
> However, it is a different thing, and for some packages |
128 |
> it is not a replacement at all. |
129 |
|
130 |
I agree that INSTALL_MASK is a different thing, and that's why I don't |
131 |
think we need to do step 1) in his masterplan; we can do that in |
132 |
parallel and push out later, as a means to at least filter the specific |
133 |
language files easily when installing a binary package which includes |
134 |
all translations (was built with LINGUAS unset to not filter any with |
135 |
autotools; or a superset of what you need on install on that machine). |
136 |
|
137 |
> For instance, the default language of mplayer will depend on |
138 |
> the first entry of LINGUAS, independent of INSTALL_MASK. |
139 |
> That's why I suggested that INSTALL_MASK should actually |
140 |
> not be discussed at all in this context. |
141 |
|
142 |
This is not the case since long ago as far as I look, as it was a bug |
143 |
and fixed long ago. |
144 |
USE_EXPAND can not express any ordering, portage probably sorts the |
145 |
list alphabetically too. |
146 |
LINGUAS as used upstream does not imply any order either. |
147 |
Runtime locale environment variables like LC_MESSAGES are supposed to |
148 |
affect what the "default" language is at startup; we are not windows. |
149 |
|
150 |
|
151 |
Mart |