1 |
Ühel kenal päeval, K, 01.06.2016 kell 12:18, kirjutas Mart Raudsepp: |
2 |
> Ühel kenal päeval, T, 31.05.2016 kell 14:49, kirjutas Michał Górny: |
3 |
> > Since the previous thread doesn't seem to have brought any good |
4 |
> > solution to the problem other than stopping to (ab)use LINGUAS |
5 |
> > as USE_EXPAND, I would like to start a RFC on a draft solution that |
6 |
> > I'd like afterwards to propose to the Council. |
7 |
> > |
8 |
> > |
9 |
> > Rationale |
10 |
> > --------- |
11 |
> > |
12 |
> > The direct reason for this is that LINGUAS is treated as non- |
13 |
> > standard |
14 |
> > special variable by multiple build systems. This includes the |
15 |
> > following |
16 |
> > problems: |
17 |
> > |
18 |
> > 1. no localizations are installed if it is set to an empty value |
19 |
> > (which |
20 |
> > happens in EAPI 5 when the ebuild does not use the flags), |
21 |
> |
22 |
> Why not just add a USE_EXPAND_DONTTOUCH variable to profiles, like |
23 |
> there is already a USE_EXPAND_HIDDEN, which tells the PM to not play |
24 |
> with the envvar, and just use it for USE expansion when the ebuild |
25 |
> does |
26 |
> use it? |
27 |
> Point being, it leaves it unset, when it's unset, and it leaves it |
28 |
> set |
29 |
> to empty value or a value when it is so. |
30 |
> |
31 |
> Obviously with a better name than USE_EXPAND_DONTTOUCH, but you get |
32 |
> the idea. |
33 |
> |
34 |
> I suppose this doesn't solve the case of PM not knowing about what is |
35 |
> inside a binary package, but if said variable also affected the |
36 |
> metadata of the result, this should be possible to handled with some |
37 |
> PM work, while not duplicating places to set languages to be |
38 |
> compiled/installed. |
39 |
> |
40 |
> The common case should be to support language x, y and z, and not |
41 |
> wanting to change that, and never or rarely build binary packages |
42 |
> (just as a backup before upgrade). |
43 |
> This is how I believe Gentoo is used as a source based distribution. |
44 |
> |
45 |
|
46 |
That said, I didn't like this being made a USE_EXPAND from the start, |
47 |
as it does something else - control what huge language packs get |
48 |
installed, as opposed to what stripping of files and file contents is |
49 |
done. And LINGUAS is quite a different beast, due to dialects, having |
50 |
special rules of implicit handling (e.g, you have a dialect in LINGUAS, |
51 |
but no specific translations exist for that language, you still get the |
52 |
main one instead; or was it vice-versa). |
53 |
But I don't think we need to wait for the INSTALL_MASK bits to swap the |
54 |
USE_EXPAND over to L10N or some other name (maybe something that |
55 |
denotes likely extra downloads of langpacks). We still have LINGUAS, |
56 |
which we might want to document better (with the binary package caveats |
57 |
mentioned, etc), and localepurge that end results in the same result as |
58 |
with the proposed INSTALL_MASK. |
59 |
|
60 |
Though this shouldn't demotivate to make this group feature for |
61 |
INSTALL_MASK happen regardless. The lingua groups should probably be |
62 |
with wildcards like <path>/pl/... AND <path>/pl_*/... to cover |
63 |
dialects, when you don't have dialect groups. |
64 |
|
65 |
Additionally I don't think there's harm in filtering languages out |
66 |
manually based on LINGUAS after all this is done still (LINGUAS not |
67 |
being a USE_EXPAND), if the upstream build system itself doesn't. Might |
68 |
want to take more care about dialects though. |
69 |
|
70 |
` |
71 |
Mart |