From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id DAD1B13829C for ; Wed, 1 Jun 2016 09:23:40 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E9D81234015; Wed, 1 Jun 2016 09:23:32 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E3ECFE0854 for ; Wed, 1 Jun 2016 09:23:31 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1b82N1-0008DQ-Fh for gentoo-dev@lists.gentoo.org; Wed, 01 Jun 2016 11:23:23 +0200 Received: from bois.imp.fu-berlin.de ([160.45.40.234]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Jun 2016 11:23:18 +0200 Received: from martin by bois.imp.fu-berlin.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Jun 2016 11:23:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Martin Vaeth Subject: [gentoo-dev] Re: [RFC] Masterplan for solving LINGUAS problems Date: Wed, 1 Jun 2016 09:23:09 +0000 (UTC) Message-ID: References: <20160531144926.4937d77a.mgorny@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: bois.imp.fu-berlin.de User-Agent: slrn/pre1.0.0-26 (Linux) X-Archives-Salt: 2cdafdae-c754-4540-9c38-5e3873d328db X-Archives-Hash: 0985bc362bfe9de5e12f85b746bbe951 Michał Górny wrote: > > 1. Get approval on INSTALL_MASK GLEP [1] and finish implementing it > in Portage. As already mentioned by some, INSTALL_MASK is something else than LINGUAS, because LINGUAS involves also files which are generated by the build system. Although I appreciate a more configurable INSTALL_MASK, this should not be mixed with the LINGUAS problem. > 2. Introduce a new USE_EXPAND that can be used to control localizations > whenever this is really required (dependencies, large files, etc.). > Let's use L10N as a draft name for it. Just to be sure that there is no misunderstanding: L10N should take the role which LINGUAS currently has for most packages from the user perspective. In other words, all ebuilds for packages whose build systems treat LINGUAS in a clean way (not relying on order etc.) and which currently have IUSE=linuguas_* will very likely contain corresponding ISUE=l10n_* and the line export LINGUAS=$L10N Therefore, I suggest to put this line in l10n.eclass (perhaps with a mechanism to avoid it for some exceptional packages which have to treat LINGUAS differently.) This way, none of these ebuilds inheriting l10n needs to be patched. > 3. Fix all packages using LINGUAS as USE_EXPAND, either by converting > to L10N or by removing the needless flags. I would strongly discourage doing the latter (unless IUSE=linguas_* was there only by mistake): When users change their L10N (or USE-flags), users should be able to see which packages need a recompilation when using emerge -N. Also for binary packages, it must be easily possible to see changes. See the more lengthy explanation below. > Request changing LINGUAS to L10N in make.conf, + > and make LINGUAS considered an 'advanced variable' for > implicit localization control (i.e. passed through to build systems). With only some rare exceptions (e.g. where the order matters), ebuilds should better set this variable according to IUSE=l10n_*. It would be better if these exceptions would not have to exist at all, i.e. if e.g. the ebuilds for packages for which the order of LINGUAS matters also use IUSE=l10n_* and introduce other USE flags to specify the order somehow (AFAIK only mplayer is involved, and for this only the first item is important, so that one can introduce e.g. IUSE=default_l10n_* variables for which exactly one must be set, or something similar.) Indeed, these exceptions are very inconvenient for the user as well as for the package manager: 1) In contrast to packages with L10N, the user cannot see with tools like eix for which linguas a certain package is installed. In fact, the user would have to analyze the compressed environment file find this out (this is also very package manager specific): 2) Even worse for binary packages. 3) The package manager cannot see after a change of LINGUAS, which packages need a recompilaten. 4) The same for binary packages. > Recommend clean INSTALL_MASK solution instead. I would also not mix these unrelated things in the documentation. One can hint that this takes additional actions for build systems not honouring L10N correctly, but usually it is not a substitute for setting L10N (or LINGUAS for the exceptional packages) but only a supplement.