Raymond Jennings <shent...@gmail.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.
