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

[Michał Górny]

On Sat, 21 May 2016 20:14:46 +1200
Kent Fredric <kentfredric@×××××.com> wrote:

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

Yes, that's one side of the problem. The other is that this was done
like this intentionally (i.e. to have USE flags implicitly converted
into LINGUAS). Just someone didn't have enough foresight where this
would lead.

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

This still leaves the problem: how to enforce this? As long as LINGUAS
leaks into ebuild env (either from USE_EXPAND magic, from make.conf or
from parent env), we're in trouble.

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

Yes, exactly. Though my plan was for it to be more like:

  INSTALL_MASK="-@linguas @linguas_pl"

or alike. Though it's all implementation detail.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>