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

[Martin Vaeth]

Raymond Jennings <shentino@×××××.com> wrote:
>
> I'd honestly as a minor issue like ot know why we called it linguas in the
> first place.
> [...]
> I think though I should also point out...don't we already have existing
> ebuilds that expose LINGUAS options in their USE flags?

From this posting, it is obvious that the discussion between mgorny
and me was not well understandable, so I try to summarize the
situation:

The variable name LINGUAS was not chosen by gentoo:
autotools based build systems (and some others) support
this variable to control, for which languages some support is
installed. The effect can be that simply some files are (not)
installed, but the effect can also be much more complex:
It really depends on the package.

Gentoo has chosen this name so that as a side effect of setting
USE=linguas_* you also get a correct LINGUAS variable exported
(according to the USE-settings and your settings and according
to the ebuild's IUSE.)
These are the package with LINGUAS options in their USE flags
which you mentioned above.

This had the advantage that no additional code except a correct
IUSE is needed for these ebuilds. (That's why gentoo has chosen
this name).

It had the disadvantage that:
1. Ebuilds without handling IUSE=linguas_* explicitly (or
with wrong values, because maintainers did not care about the
values) had problems.
2. Some packages which needed a different handling of LINGUAS
(like respecting the order) also had problems.

There are at least the following solutions to these disadvantages:

a)
One _could_ solve problem 1 simply by not touching LINGUAS if
IUSE=linguas_* is not in the ebuild. (Main problem with this
solution: It is not PMS compatible; one needs e.g.
an exception for LINGUAS).
In a similar manner, one could solve problem 2 by allowing
ebuilds to modify LINGUAS at build time (which is perhaps
also not PMS compatible).

b)
Or one could, for all packages with LINGUAS in their USE-flag
simply rename IUSE=linguas_* to IUSE=l10n_* and set
export LINGUAS=$L10N
in these ebuilds (this would require practically no manual ebuild
editing if one does it in the l10n.eclass).

I had originally understood mgorny's suggestion such that b)
is meant, and I would complain neither against a) nor b).

But in his reply, mgorny says that, moreover, he wants to
remove the l10n.eclass, more precisely, that he considers
it as broken that packages use IUSE=l10n_* for setting
LINGUAS.

This suggestion means that setting LINGUAS can be done
*only* in a hackish way by the user, "hidden" from the
package manager, not in the clean way as it is currently
done by those ebuilds with LINGUAS in their use-falgs.

I agree with him that a hidden setting is a bad idea.
Where our opinions strongly differ is whether a way to
cleanly set LINGUAS should be provided (e.g. by allowing
IUSE=l10n_* to modify LINGUAS appropriately, and make this
the "good" way instead calling it a "broken" way which
should be avoided.)

The INSTALL_MASK is an independent thing which for _many_
packages "by accident" can be used with a similar effect as
setting LINGUAS (because many packages use LINGUAS only to
determine the files which they install).
However, it is a different thing, and for some packages
it is not a replacement at all.
For instance, the default language of mplayer will depend on
the first entry of LINGUAS, independent of INSTALL_MASK.
That's why I suggested that  INSTALL_MASK should actually
not be discussed at all in this context.