On 05/31/2016 05:49 AM, Michał Górny wrote: > Hello, everyone. > > Since the previous thread doesn't seem to have brought any good > solution to the problem other than stopping to (ab)use LINGUAS > as USE_EXPAND, I would like to start a RFC on a draft solution that > I'd like afterwards to propose to the Council. > > > Rationale > --------- > > The direct reason for this is that LINGUAS is treated as non-standard > special variable by multiple build systems. This includes the following > problems: > > 1. no localizations are installed if it is set to an empty value (which > happens in EAPI 5 when the ebuild does not use the flags), > > 2. there were historical cases where order of LINGUAS mattered. > > Those problems can't be reasonably solved within the scope of > USE_EXPAND. Furthermore, the use of flags to control localizations is > causing the following problems: > > a. maintaining correct flag list is a serious maintenance burden, > especially that differences in build systems make it hard to figure out > the 'most correct' set automatically, > > b. missing flags result in localizations being silently dropped, with > no clear way (i.e. for QA check) to detect that, > > c. large number of additional USE flags make it pretty much impossible > to limit localizations this way when using binary packages. > > > The plan > -------- > > 1. Get approval on INSTALL_MASK GLEP [1] and finish implementing it > in Portage. > > 2. Introduce a new USE_EXPAND that can be used to control localizations > whenever this is really required (dependencies, large files, etc.). > Let's use L10N as a draft name for it. > > 3. Fix all packages using LINGUAS as USE_EXPAND, either by converting > to L10N or by removing the needless flags. > > 4. Remove LINGUAS from USE_EXPAND, therefore removing the special EAPI > rules from the variable. > > 5. Release a news item explaining the users the change, > and the necessary action. Request changing LINGUAS to L10N > in make.conf, and make LINGUAS considered an 'advanced variable' for > implicit localization control (i.e. passed through to build systems). > Recommend clean INSTALL_MASK solution instead. > > The example 'new' make.conf would probably look like: > > # controlling e.g. langpacks > L10N="en_US pl" > # stripping unneeded files > INSTALL_MASK="@linguas -@linguas_pl" > > > Your thoughts? > > > [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:INSTALL_MASK >
I think this idea has some potential, but would there be a way for a user to choose L10N *or* INSTALL_MASK instead of both? If I understand correctly, a person who wanted all of their system to be en_US only, but wanted to take part in translation of some other project, would need to add the other locales directly to L10N, then somehow mask them out for other packages. Or the reverse: leave L10N="en_US" or something, and somehow enable other languages in that specific package. Is there a package-level option for this? Users can set their locales in /etc/locale.gen, and that handles things globally, but what about the user that doesn't want to include that for all of their packages? This seems like an all-or-nothing thing, lacking in granularity. If I'm wrong, please clarify so I can understand better. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: OpenPGP digital signature
