Hi, On Tue, 31 May 2016 14:49:26 +0200 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"
Users will have extra burden because of this change. We should make user experience simpler, not more and more difficult. With proposed change users will need to manage two lists for the same functionality: L10N and INSTALL_MASK. The latter one is being used for many purposes and people may be confused by requirement to put @linguas-like directives there. It's like we'll force to put all USE_EXPAND flags explicitly in the USE variable. What about different locales for the same language? E.g. there is ru, ru_RU and ru_RU_0 for Russian (I have no clue what ru_RU_0 is supposed to mean). What are planes for this varians? Will @lingual_ru contain all of them or only some? What about man pages? They are also controlled by LINGUAS (at least for some packages), but will be out of control with proposed changes. If we are going to do an instant move from LINGUAS to L10N (no graced period as discussed here on another thread), why to rename variable in the first place? It will be a nice move towards our users if INSTALL_MASK will be automatically populated based on L10N list with ability to override it if really needed, e.g. user needs L10N for en only (e.g. large docs), but wants some other languages for localization files. Best regards, Andrew Savchenko
pgpHhtynQ4sQp.pgp
Description: PGP signature
