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
signature.asc
Description: OpenPGP digital signature
