Re: [gentoo-dev] [RFC] How to deal with LINGUAS mess?

[Kent Fredric]

On 21 May 2016 at 19:41, Michał Górny <mgorny@g.o> wrote:
> Hello,
>
>
> Those of you who read my blog post on LINGUAS [1] may already know
> what's going on. For those who didn't, short summary:
>
> In EAPI 5 and newer, all variables listed in USE_EXPAND are supposed to
> be unconditionally exported with their values reduced to enabled USE
> flags listed in IUSE. In particular, this means that if ebuild does not
> list any linguas_* flags in IUSE, PM exports *empty* LINGUAS (i.e.
> disables all localizations with the implicit gettext behavior).
>
> Portage had so far some ugly hack-logic that tried to keep LINGUAS
> working somehow in place. However, the patches to enable PMS-compliant
> behavior are on their way, so it's about time to decide what to do
> about LINGUAS.
>
>
> I see the following possibilities:
>
> 1. We start explicitly listing linguas_* in all ebuilds, no matter how
> tiny they are. Maintainers are required to keep IUSE up-to-date
> and users are forced to rebuild a lot. This is also a QA violation
> in terms of invalid use of USE flags.
>
> 2. We hack-unset LINGUAS in ebuilds. This is a lot of effort, easy to
> miss and probably would need to repeated for every single phase anyway
> due to how global variables are handled in PMS. Additionally, it may
> break at some point since those variables are likely expected to be
> read-only anyway.
>
> 3. We remove LINGUAS from USE_EXPAND and stop using it. If ebuilds have
> a good reason to use flags for localization, we introduce a new,
> non-colliding USE_EXPAND for that. We also ask users to replace LINGUAS
> with the new flag in their make.conf files. LINGUAS gets the original
> upstream behavior back, and we eventually discourage it in favor of new
> INSTALL_MASK features (WiP) [2].
>
> 4. We fix build systems not to do magic depending on whether LINGUAS
> is unset or set-to-empty. Instead, we could some special special value
> like '-' to signify not installing localizations at all. But that's
> upstream thing to do, and breaks backwards compatibility with existing
> systems disabling localizations.
>
>
> Your thoughts?

I think its a regretful situation we find ourselves in where
portage/PMS control values that have to go via ENV, leak beyond ENV
into packaging.

This has already been a bit of a worry for us, because we may have
wanted to use PERL_ as a prefix for env vars in an eclass, but there's
a possibility of accidentally picking the same ENV var that is
inherently used in some perl part.
( And at very least, `perl -V` shows all ENV vars that are prefixed
with PERL_ .... eg: PERL_MOM_YOURS=1 perl -V )

Though I just don't see how we can generically avoid that scope
leakage, because this is bash, and we're short on private ways to pass
control values around, other than going crazy on functions.

The only thing I thought of when reading the writeup was tagged
install mask verbs.

That is:

- Always install all language support possible by default.
- Have an ebuild mapping of some description that annotates "files X
add support for languages ( y, z, x )"

And then maybe you'd have a parameterized INSTALL_MASK system where you could do

INSTALL_MASK_RULES="linguas(-* en)"

Then it would be "Packager decides" if they want to trip a rebuild at
the end user when they "discovered" certain files pertain to specific
language support.

Then the only reason you'd need USE flags is if you wanted to toggle
compile time support that pulled in dependencies to support the
language in question.


-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL