| 1 |
How can I select different linguas for individual packages with this |
| 2 |
approach? |
| 3 |
|
| 4 |
Michał Górny wrote: |
| 5 |
|
| 6 |
> Hello, everyone. |
| 7 |
> |
| 8 |
> Since the previous thread doesn't seem to have brought any good |
| 9 |
> solution to the problem other than stopping to (ab)use LINGUAS |
| 10 |
> as USE_EXPAND, I would like to start a RFC on a draft solution that |
| 11 |
> I'd like afterwards to propose to the Council. |
| 12 |
> |
| 13 |
> |
| 14 |
> Rationale |
| 15 |
> --------- |
| 16 |
> |
| 17 |
> The direct reason for this is that LINGUAS is treated as non-standard |
| 18 |
> special variable by multiple build systems. This includes the following |
| 19 |
> problems: |
| 20 |
> |
| 21 |
> 1. no localizations are installed if it is set to an empty value (which |
| 22 |
> happens in EAPI 5 when the ebuild does not use the flags), |
| 23 |
> |
| 24 |
> 2. there were historical cases where order of LINGUAS mattered. |
| 25 |
> |
| 26 |
> Those problems can't be reasonably solved within the scope of |
| 27 |
> USE_EXPAND. Furthermore, the use of flags to control localizations is |
| 28 |
> causing the following problems: |
| 29 |
> |
| 30 |
> a. maintaining correct flag list is a serious maintenance burden, |
| 31 |
> especially that differences in build systems make it hard to figure out |
| 32 |
> the 'most correct' set automatically, |
| 33 |
> |
| 34 |
> b. missing flags result in localizations being silently dropped, with |
| 35 |
> no clear way (i.e. for QA check) to detect that, |
| 36 |
> |
| 37 |
> c. large number of additional USE flags make it pretty much impossible |
| 38 |
> to limit localizations this way when using binary packages. |
| 39 |
> |
| 40 |
> |
| 41 |
> The plan |
| 42 |
> -------- |
| 43 |
> |
| 44 |
> 1. Get approval on INSTALL_MASK GLEP [1] and finish implementing it |
| 45 |
> in Portage. |
| 46 |
> |
| 47 |
> 2. Introduce a new USE_EXPAND that can be used to control localizations |
| 48 |
> whenever this is really required (dependencies, large files, etc.). |
| 49 |
> Let's use L10N as a draft name for it. |
| 50 |
> |
| 51 |
> 3. Fix all packages using LINGUAS as USE_EXPAND, either by converting |
| 52 |
> to L10N or by removing the needless flags. |
| 53 |
> |
| 54 |
> 4. Remove LINGUAS from USE_EXPAND, therefore removing the special EAPI |
| 55 |
> rules from the variable. |
| 56 |
> |
| 57 |
> 5. Release a news item explaining the users the change, |
| 58 |
> and the necessary action. Request changing LINGUAS to L10N |
| 59 |
> in make.conf, and make LINGUAS considered an 'advanced variable' for |
| 60 |
> implicit localization control (i.e. passed through to build systems). |
| 61 |
> Recommend clean INSTALL_MASK solution instead. |
| 62 |
> |
| 63 |
> The example 'new' make.conf would probably look like: |
| 64 |
> |
| 65 |
> # controlling e.g. langpacks |
| 66 |
> L10N="en_US pl" |
| 67 |
> # stripping unneeded files |
| 68 |
> INSTALL_MASK="@linguas -@linguas_pl" |
| 69 |
> |
| 70 |
> |
| 71 |
> Your thoughts? |
| 72 |
> |
| 73 |
> |
| 74 |
> [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:INSTALL_MASK |
| 75 |
> |
Archives