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 11B5713829B for ; Sun, 29 May 2016 13:05:15 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CCF6B1437C; Sun, 29 May 2016 13:04:17 +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 4D5EA14373 for ; Sun, 29 May 2016 13:04:06 +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 974C4340B90; Sun, 29 May 2016 13:04:01 +0000 (UTC) Date: Sun, 29 May 2016 14:30:08 +0200 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: Kent Fredric Cc: gentoo-dev , qa@gentoo.org Subject: Re: [gentoo-dev] [RFC] How to deal with LINGUAS mess? Message-ID: <20160529143008.18bdbdce.mgorny@gentoo.org> In-Reply-To: References: <20160521094128.0a7c7766.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_/KNjxM1UyabAMqiPAwLwvfR="; protocol="application/pgp-signature" X-Archives-Salt: bfe840b8-b4e9-42e0-b837-7ec3e324dbce X-Archives-Hash: 708b17a40cbb9b5dd9be4da8fa16a376 --Sig_/KNjxM1UyabAMqiPAwLwvfR= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, 21 May 2016 20:14:46 +1200 Kent Fredric wrote: > On 21 May 2016 at 19:41, Micha=C5=82 G=C3=B3rny 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? =20 >=20 > 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. >=20 > 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=3D1 perl -V ) >=20 > 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. >=20 > That is: >=20 > - 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 )" >=20 > And then maybe you'd have a parameterized INSTALL_MASK system where you c= ould do >=20 > INSTALL_MASK_RULES=3D"linguas(-* en)" >=20 > 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. >=20 > 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=3D"-@linguas @linguas_pl" or alike. Though it's all implementation detail. --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/KNjxM1UyabAMqiPAwLwvfR= Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXSuDQXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZO//QQAIkNKxnh2k8ivvGrpY987E2O Z9RLPgNCx18IjpeNOMlHBUVG6DWIFK6wlBvFppJ83jT5H2y+jJG++Ne3nqRPgPnv 6EVh4d7fprXil/M6Pc9Ds6RwerywS6PRK7RlN7KxVMHwKt8sIogIFlYzspFG2vWn cQ1v1P0ta7y4Ggxp8vFk86KpPheI8E/Kf1JsC+ciBfSNWqX7UkJXxyy7mbwF79gN SQDd9BDUSSInZgK/awG65lll/iG6gbHyyxR0RFG59VfnWMohacuKwW+MsR7UW+sW UeZyZGdYMPQRK7T8HZB6hqAe7cWDgcNe6ga3ysVAaZJ3tnZqYtCeoaUST1K63mfX MtBC13VU7yLGO1Hz+EFebp48dCY/sTm+cYJhHklBqNOp2txPBQyhHPrEggnExrKU FFZ1R+MLUMzKKkrDYhlYSjfYys7JMF5yAxOQtSS0MO4p5ku4a/ZSLMXSW7rTp6RZ 7FtJOE03qedmSi7zPYszKg+jZou/sT54SIcb22lizKpCsQVGJGH/4s5P6ee+HW89 XtDsCvoafRckQulMs8C/oPNAA9/sVyiw0ZkdHCLbS5Pwl/hw2QSZ3WKYlI+7y+U6 HXrL1/xXZzeYUj7Nbw0HB1dqWgVW+6CCAVOK4yRG58fxdZVJV3V60LLgAcn3GCSg KUP7HSG1c959D5osML7p =EGXP -----END PGP SIGNATURE----- --Sig_/KNjxM1UyabAMqiPAwLwvfR=--