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 49D551385AB for ; Sun, 20 Jan 2013 22:33:41 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7D45621C0A9; Sun, 20 Jan 2013 22:33:22 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E330221C008 for ; Sun, 20 Jan 2013 22:33:15 +0000 (UTC) Received: from pomiocik.lan (213-238-105-25.adsl.inetia.pl [213.238.105.25]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id E07DD33DAFD; Sun, 20 Jan 2013 22:33:12 +0000 (UTC) Date: Sun, 20 Jan 2013 23:33:39 +0100 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: gentoo-dev@lists.gentoo.org Cc: slyfox@gentoo.org Subject: Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib Message-ID: <20130120233339.15b57eab@pomiocik.lan> In-Reply-To: <20130121010556.27f8fac6@sf> References: <20130120201131.5afcbf48@pomiocik.lan> <20130121010556.27f8fac6@sf> Organization: Gentoo X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.14; 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-SHA256; boundary="Sig_/9+dw6DuTY951xZDWE2H7_S4"; protocol="application/pgp-signature" X-Archives-Salt: 2457cb57-664e-4b94-b958-eff8d1ebb005 X-Archives-Hash: 44487a922ad35afea9aea34947549748 --Sig_/9+dw6DuTY951xZDWE2H7_S4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, 21 Jan 2013 01:05:56 +0300 Sergei Trofimovich wrote: > On Sun, 20 Jan 2013 20:11:31 +0100 > Micha=C5=82 G=C3=B3rny wrote: >=20 > > There is a fair interest in multilib and while still early, it would be > > a good moment to decide on how USE flags to use for it. > >=20 > > The current attempts are mostly using USE=3Dmultilib which is not really > > expressive and poor. What I would go for is a clear variable specifying > > which targets package is built for. >=20 > You just need to add 'ABI' and 'MULTILIB_ABIS' to > "emerge --info ${pkg}" output. No, that's not the same. It's like python.eclass vs new Python eclasses. Cheap hidden logic vs explicit USE-dep logic. > Do you plan to keep precise depends for packages? > like glibc[abi_x32]/gcc[abi_x32] for all libraries requesting x32. Yes. ${MULTILIB_USEDEP} is for that (it currently evaluates to 'multilib?'). > What to do if someone builds a package only with non-default ABI? > (it means installed package does not quite work for default ABI) Well, I was asking the same question. That was what my q1 was asking, I think you misunderstood it. > like on ABI=3Damd64 media-libs/glu[ABI=3Dx32] could not be used by > any of ABI=3Damd64 users. >=20 > In order to track such depends precisely you would need to add > ABI flags to each revdep recursively. It's quite invasive. Is it worth > the effort? A good point. I'd say that the default impl should be built then. But... how about making it a USE flag with use.force logic? That way, it would be explicitly visible, and if someone really wanted to disable it, he would be able to do it on his own responsibility. > Currently USE=3Dmultilib means 'build for all toolchain-supported' ABIs. > It looks clean and short. But if we wanted to introduce x32, it would become no longer clean. I believe many of our users want/need multilib only for running 32-bit apps on amd64 (like wine). Why would they need x32 libraries? But on the other hand, if we follow that logic we will probably have no reason to enable x32 on amd64 for a long time. Maybe mips ABIs will be a better example? > > 2) do we want irrelevant ABIs to be visible to emerge users? > >=20 > > By 2) I mean: do we want the users to see stuff like: > >=20 > > MULTILIB_ABIS=3D"amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1) > > (-ppc64_abi2) (-ppc64_abi3) ..." >=20 > Would adding irrelevant ABIs trigger rebuilds on world update? That's a good question, especially wrt USE_EXPAND_HIDDEN. > Do you intermingle gentoo's $ARCH and ABI? I think not. I believe that ABIs shall be defined by profiles. If someone tries to set ARCH for something incorrect for the profile, that's not something we shall support, I believe. > How many ABI vars do you expect to see for simple "common" cases? >=20 > x86_64-pc-linux-gnu-gcc -m32 (host ARCH=3Damd64) > x86_64-pc-linux-gnu-gcc -m64 (host ARCH=3Damd64) > x86_64-pc-linux-gnu-gcc -mx32 (host ARCH=3Damd64) > i686-pc-linux-gnu-gcc -m32 (host ARCH=3Dx86) > i686-pc-linux-gnu-gcc -m64 (host ARCH=3Dx86) > i686-pc-linux-gnu-gcc -mx32 (host ARCH=3Dx86) >=20 > 3 or 6? I think 3 will be enough. > Looks like insane amount of metadata growth for each > plagued package. I don't think metadata is really important here. I believe that the amount of additional metadata introduced by the packages affected by multilib is not really one worth worrying. --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/9+dw6DuTY951xZDWE2H7_S4 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iJwEAQEIAAYFAlD8cMMACgkQfXuS5UK5QB3qWgP/WZXGzCkTnmnnckr8Po2DVnYk iAVZCgim/+xbUvvxZebX+viDby2IdNEuHFimj0e4t0XVO0oeeiNbm2W6a0hFEqdt zjkP3m7VZZnFt6WzmwOPH/MQ2krLuyiS8HCASdKhEHMZCtLaXurSKsUbCUqdyudq FPMTECvKJGibZuejt8o= =weHS -----END PGP SIGNATURE----- --Sig_/9+dw6DuTY951xZDWE2H7_S4--