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 5148B13829C for ; Tue, 31 May 2016 12:49:45 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EF89014203; Tue, 31 May 2016 12:49:35 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E7DD221C039 for ; Tue, 31 May 2016 12:49:34 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id D5EC8340CAC; Tue, 31 May 2016 12:49:32 +0000 (UTC) Date: Tue, 31 May 2016 14:49:26 +0200 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: Cc: Subject: [gentoo-dev] [RFC] Masterplan for solving LINGUAS problems Message-ID: <20160531144926.4937d77a.mgorny@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) 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: multipart/signed; micalg=pgp-sha512; boundary="Sig_/Q2lnqri9axE9qeFN+qjHvPg"; protocol="application/pgp-signature" X-Archives-Salt: 807b76e8-63ad-478f-bc64-f7f8c6d6b4ad X-Archives-Hash: 41e09d1ddc8b30abb9f9d21d205b7b82 --Sig_/Q2lnqri9axE9qeFN+qjHvPg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, everyone. Since the previous thread doesn't seem to have brought any good solution to the problem other than stopping to (ab)use LINGUAS as USE_EXPAND, I would like to start a RFC on a draft solution that I'd like afterwards to propose to the Council. Rationale --------- The direct reason for this is that LINGUAS is treated as non-standard special variable by multiple build systems. This includes the following problems: 1. no localizations are installed if it is set to an empty value (which happens in EAPI 5 when the ebuild does not use the flags), 2. there were historical cases where order of LINGUAS mattered. Those problems can't be reasonably solved within the scope of USE_EXPAND. Furthermore, the use of flags to control localizations is causing the following problems: a. maintaining correct flag list is a serious maintenance burden, especially that differences in build systems make it hard to figure out the 'most correct' set automatically, b. missing flags result in localizations being silently dropped, with no clear way (i.e. for QA check) to detect that, c. large number of additional USE flags make it pretty much impossible to limit localizations this way when using binary packages. The plan -------- 1. Get approval on INSTALL_MASK GLEP [1] and finish implementing it in Portage. 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. 3. Fix all packages using LINGUAS as USE_EXPAND, either by converting to L10N or by removing the needless flags. 4. Remove LINGUAS from USE_EXPAND, therefore removing the special EAPI rules from the variable. 5. Release a news item explaining the users the change, and the necessary action. 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). Recommend clean INSTALL_MASK solution instead. The example 'new' make.conf would probably look like: # controlling e.g. langpacks L10N=3D"en_US pl" # stripping unneeded files INSTALL_MASK=3D"@linguas -@linguas_pl" Your thoughts? [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:INSTALL_MASK --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/Q2lnqri9axE9qeFN+qjHvPg Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXTYhWXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZOlXkP/1VCfzqIywdcxm9ziFb8OhL4 uMrJun4uUmBcO6+/3JEee6ZR2uuQalI8lGt8PNkG26XSjBKlFyIjUfhvnHoKZnjp uZhvR/+joDvGeTGJ8d0C3i7Dji+Gzd/MPIyg/DsFxwx4uR3xIFlXmFLLE2UGaXNk P9hXBuqtheWzTceGAEfxFc39smJWqRM4Bln8kK8zdKX3QWMkEbxKMV+TMc3mDLR3 lxB48Z9rzz7K+PafmrYkyEp0MvpMZUNsAwKc4fqnpYyuulyYqtAaMBRqlmG5+8Ee yzViqH6MKAL9qk/2JWsODLxwz+dB/veE0n67QsU6cNktWEg0LV4cNGMroU6rSUmi bUP0uKD3yVkFr6LgvTu0O9UZpZ8rPkfcjQKTBWruYKDg+sd006NWcC3seuaLGTq1 1Zei+uDr5FqTUeIrzWhzdhUQk9rGfX+7wI5kIbSXtdZVot2+Df0+VGITyH8ilhji 9zJrPWc0S5xIAvuaLhdT/p4OhG1At2rf4S+eYVZfSneaD0J1Fdi9mpoJGH+DM+t2 vZ2gqmMLzpAOxS1WBMNKaxf3DjqmjPENF5cZWKfgliQj0xwOd0zrwwUmFqxxqgrK JEj3yMdfsirEMEQeOPqeWbdKqTSI2MYNu0We+peWkxJRjHWuQ0rdR7cZhLssVsQ7 Ik2IBcjfVCcXk5eJImsZ =XWQV -----END PGP SIGNATURE----- --Sig_/Q2lnqri9axE9qeFN+qjHvPg--