Re: [gentoo-dev] [RFC] Masterplan for solving LINGUAS problems

[Daniel Campbell]

On 05/31/2016 10:31 AM, Daniel Campbell wrote:
> 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.
>

I forgot to include that I think the INSTALL_MASK groups, even if not
implemented for this issue, are a great idea. It would allow users to
target specific things like "get rid of info pages", "no systemd unit
files", etc, in a way that is controlled by the repo (or an override in
/etc/portage somewhere). It prevents more ebuild bloat, too.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6