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

[Martin Vaeth]

Michał Górny <mgorny@g.o> wrote:
>
> 1. Get approval on INSTALL_MASK GLEP [1] and finish implementing it
> in Portage.

As already mentioned by some, INSTALL_MASK is something else than
LINGUAS, because LINGUAS involves also files which are generated
by the build system. Although I appreciate a more configurable
INSTALL_MASK, this should not be mixed with the LINGUAS problem.

> 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.

Just to be sure that there is no misunderstanding:
L10N should take the role which LINGUAS currently has for most
packages from the user perspective.
In other words, all ebuilds for packages whose build systems treat
LINGUAS in a clean way (not relying on order etc.)
and which currently have IUSE=linuguas_* will very likely contain
corresponding ISUE=l10n_* and the line

export LINGUAS=$L10N

Therefore, I suggest to put this line in l10n.eclass
(perhaps with a mechanism to avoid it for some exceptional packages
which have to treat LINGUAS differently.)
This way, none of these ebuilds inheriting l10n needs to be patched.

> 3. Fix all packages using LINGUAS as USE_EXPAND, either by converting
> to L10N or by removing the needless flags.

I would strongly discourage doing the latter (unless IUSE=linguas_*
was there only by mistake):  When users change their L10N (or
USE-flags), users should be able to see which packages need a
recompilation when using emerge -N. Also for binary packages, it
must be easily possible to see changes.
See the more lengthy explanation below.

> 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).

With only some rare exceptions (e.g. where the order matters),
ebuilds should better set this variable according to IUSE=l10n_*.
It would be better if these exceptions would not have to exist
at all, i.e. if e.g. the ebuilds for packages for which the order
of LINGUAS matters also use IUSE=l10n_* and introduce other
USE flags to specify the order somehow (AFAIK only mplayer is
involved, and for this only the first item is important, so that
one can introduce e.g. IUSE=default_l10n_* variables for which exactly
one must be set, or something similar.)
Indeed, these exceptions are very inconvenient for the user
as well as for the package manager:

1) In contrast to packages with L10N, the user cannot see with
tools like eix for which linguas a certain package is installed.
In fact, the user would have to analyze the compressed environment
file find this out (this is also very package manager specific):

2) Even worse for binary packages.

3) The package manager cannot see after a change of LINGUAS,
which packages need a recompilaten.

4) The same for binary packages.

> Recommend clean INSTALL_MASK solution instead.

I would also not mix these unrelated things in the documentation.
One can hint that this takes additional actions for build
systems not honouring L10N correctly, but usually it is
not a substitute for setting L10N (or LINGUAS for the
exceptional packages) but only a supplement.