Gentoo Archives: gentoo-dev

From: Martin Vaeth <martin@×××××.de>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: [RFC] Masterplan for solving LINGUAS problems
Date: Wed, 01 Jun 2016 09:23:40
In Reply to: [gentoo-dev] [RFC] Masterplan for solving LINGUAS problems by "Michał Górny"
1 Michał Górny <mgorny@g.o> wrote:
2 >
3 > 1. Get approval on INSTALL_MASK GLEP [1] and finish implementing it
4 > in Portage.
6 As already mentioned by some, INSTALL_MASK is something else than
7 LINGUAS, because LINGUAS involves also files which are generated
8 by the build system. Although I appreciate a more configurable
9 INSTALL_MASK, this should not be mixed with the LINGUAS problem.
11 > 2. Introduce a new USE_EXPAND that can be used to control localizations
12 > whenever this is really required (dependencies, large files, etc.).
13 > Let's use L10N as a draft name for it.
15 Just to be sure that there is no misunderstanding:
16 L10N should take the role which LINGUAS currently has for most
17 packages from the user perspective.
18 In other words, all ebuilds for packages whose build systems treat
19 LINGUAS in a clean way (not relying on order etc.)
20 and which currently have IUSE=linuguas_* will very likely contain
21 corresponding ISUE=l10n_* and the line
23 export LINGUAS=$L10N
25 Therefore, I suggest to put this line in l10n.eclass
26 (perhaps with a mechanism to avoid it for some exceptional packages
27 which have to treat LINGUAS differently.)
28 This way, none of these ebuilds inheriting l10n needs to be patched.
30 > 3. Fix all packages using LINGUAS as USE_EXPAND, either by converting
31 > to L10N or by removing the needless flags.
33 I would strongly discourage doing the latter (unless IUSE=linguas_*
34 was there only by mistake): When users change their L10N (or
35 USE-flags), users should be able to see which packages need a
36 recompilation when using emerge -N. Also for binary packages, it
37 must be easily possible to see changes.
38 See the more lengthy explanation below.
40 > Request changing LINGUAS to L10N in make.conf,
42 +
44 > and make LINGUAS considered an 'advanced variable' for
45 > implicit localization control (i.e. passed through to build systems).
47 With only some rare exceptions (e.g. where the order matters),
48 ebuilds should better set this variable according to IUSE=l10n_*.
49 It would be better if these exceptions would not have to exist
50 at all, i.e. if e.g. the ebuilds for packages for which the order
51 of LINGUAS matters also use IUSE=l10n_* and introduce other
52 USE flags to specify the order somehow (AFAIK only mplayer is
53 involved, and for this only the first item is important, so that
54 one can introduce e.g. IUSE=default_l10n_* variables for which exactly
55 one must be set, or something similar.)
56 Indeed, these exceptions are very inconvenient for the user
57 as well as for the package manager:
59 1) In contrast to packages with L10N, the user cannot see with
60 tools like eix for which linguas a certain package is installed.
61 In fact, the user would have to analyze the compressed environment
62 file find this out (this is also very package manager specific):
64 2) Even worse for binary packages.
66 3) The package manager cannot see after a change of LINGUAS,
67 which packages need a recompilaten.
69 4) The same for binary packages.
71 > Recommend clean INSTALL_MASK solution instead.
73 I would also not mix these unrelated things in the documentation.
74 One can hint that this takes additional actions for build
75 systems not honouring L10N correctly, but usually it is
76 not a substitute for setting L10N (or LINGUAS for the
77 exceptional packages) but only a supplement.


Subject Author
Re: [gentoo-dev] Re: [RFC] Masterplan for solving LINGUAS problems "Michał Górny" <mgorny@g.o>