public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Michał Górny" <mgorny@gentoo.org>
To: <gentoo-dev@lists.gentoo.org>
Cc: <qa@gentoo.org>
Subject: [gentoo-dev] [RFC] How to deal with LINGUAS mess?
Date: Sat, 21 May 2016 09:41:28 +0200	[thread overview]
Message-ID: <20160521094128.0a7c7766.mgorny@gentoo.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 2250 bytes --]

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?


[1]:https://blogs.gentoo.org/mgorny/2016/05/16/how-linguas-are-thrice-wrong/
[2]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:INSTALL_MASK

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

             reply	other threads:[~2016-05-21  7:41 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-21  7:41 Michał Górny [this message]
2016-05-21  8:14 ` [gentoo-dev] [RFC] How to deal with LINGUAS mess? Kent Fredric
2016-05-29 12:30   ` Michał Górny
2016-05-21  9:00 ` [gentoo-dev] " Ulrich Mueller
2016-05-21  9:04   ` Kent Fredric
2016-05-21  9:32     ` Ulrich Mueller
2016-05-21 19:35   ` Michał Górny
2016-05-21 12:20 ` [gentoo-dev] " Michael Orlitzky
2016-05-21 15:19 ` waltdnes
2016-05-27  7:17   ` Mart Raudsepp
2016-05-29 13:03     ` Michał Górny
2016-05-29 12:58   ` Michał Górny
2016-05-30  2:21     ` waltdnes
2016-05-30 10:47     ` Andrew Savchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160521094128.0a7c7766.mgorny@gentoo.org \
    --to=mgorny@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    --cc=qa@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox