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 EDF741387FD for ; Mon, 31 Mar 2014 22:16:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4DD22E0B39; Mon, 31 Mar 2014 22:16:29 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5542AE0B33 for ; Mon, 31 Mar 2014 22:16:28 +0000 (UTC) Received: from pomiot.lan (77-254-69-105.adsl.inetia.pl [77.254.69.105]) (using SSLv3 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 1EBED33FA95; Mon, 31 Mar 2014 22:16:25 +0000 (UTC) Date: Tue, 1 Apr 2014 00:16:17 +0200 From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= To: Cc: Subject: [gentoo-dev] Stable masks on multilib packages Message-ID: <20140401001617.42fdc3bc@pomiot.lan> Organization: Gentoo X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; 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_/Pbpkg1HB2Wc_wr=h_r9wD9q"; protocol="application/pgp-signature" X-Archives-Salt: 8b0d73c7-2cc5-4a07-95fd-4a8c73398318 X-Archives-Hash: b9b948fe22b125bd93e694bc892c9d0e --Sig_/Pbpkg1HB2Wc_wr=h_r9wD9q Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Hello, all. The late multilib ppc issues made me re-check our stable masks on abi_x86_* flags and, honestly, I'm not sure if we're doing things the right way. First, a quick summary. Let's consider dev-libs/elfutils that has a dependency on app-arch/bzip2. If we're building 32-bit elfutils, it needs 32-bit libbz2. This is enforced through a dep in form of: app-arch/bzip2[${MULTILIB_USEDEP}] that gets expanded into: app-arch/bzip2[abi_x86_32(-)?,abi_x86_64(-)?,...,abi_mips_o32(-)?,...] which means that any of the ABI_* flags that gets enabled on elfutils, needs to be enabled on bzip2 as well. Of course, some of use.forcing and masking gets applied here but that doesn't really matter. Now, since we're pretty much converting a lot of different packages, some of them are eligible for stabilization earlier than the others. However, the extra MULTILIB_USEDEPs enforce stabilizing multilib dependencies before the actual packages which made a few developers unhappy. That's why we decided to stable-mask the flags on affected packages. Since the flags are masked on stable, people can stabilize packages independently of whether their converted deps are stable or not. We will be worrying about that consistency once we decide to unmask the flags. The extra advantage of that is that we can avoid pushing stable users into the mess involved with partial conversion of emul-linux. The idea is pretty simple: we keep emul-linux for stable, and once everything is ready, we stable-unmask the flags and let stable users grok multilib. Now, to the problem. Currently we're just stable-masking abi_x86_32 on amd64. This serves the latter purpose well and seems to work for the former. This is probably because the remaining flag is use.forced (abi_x86_64 on amd64, and abi_x86_32 on x86) which seems to add it to implicit IUSE somehow. floppym has done some research w/ stable elfutils and no stable converted bzip2. It seems that if abi_x86_32 is stable.use.masked and abi_x86_64 is use.forced, repoman groks it. However, if we remove abi_x86_64 from use.force, it properly reports flag mismatch error (since no stable bzip2 has IUSE=3Dabi_x86_64). Now, I honestly have no idea if this implicit use.force behavior is PMS-y or not, and how other PMs handle it. I can't find something like this in the PMS but that doc is horribly hard to cross-reference, so I might be missing something. I'd appreciate if someone could help me with that. That said, I have an alternate idea inspired by the ppc breakage. I'm thinking of replacing the amd64 abi_x86_32 mask with a global stable mask of all abi_*_* flags on the relevant packages. Differences: 1) old solution: native flag is forced, other flags are masked. new solution: all flags are masked. 2) old solution: we need to replicate the masks properly for different arches/profiles. new solution: we can keep a single mask for all arches. 3) old solution: MULTILIB_USEDEP magically works (w/ portage at least). new solution: since all flags are disabled, MULTILIB_USEDEP is a no-op and old packages match correctly. 4) old solution: forced native flag runs the native build. new solution: fallback code runs the native build (since no flags are enabled). Your thoughts? --=20 Best regards, Micha=B3 G=F3rny --Sig_/Pbpkg1HB2Wc_wr=h_r9wD9q Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQJ8BAEBCgBmBQJTOekyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZOsdMP/j/gL6/A0MVz2ePjfKA3J9qo KFxGtGdb7axGxaBJ+tDw+7UVVoCZzeZt1Fd/ocUuxB9f5sCgRwzira8WQTiYLoKU 48YOj5KFj6Nm5iCRbbvJOC6hdmfe+DOtFGr7I3Pg9U82wX/59Y71Cr5bbLjRmEkF 9MdjseZzLjqJGZkG2isppHEg1tIUxtKHHa2/X2DXFKJE4wja0H/UVFZOrAELuf9h 8IjeJii+hqwNEcDXh5vBn6dRG9P0XT3WNHu8sotAEfSoWLk7KfRqEvc94171pY2G FCKw2M+HxB3eIKu60y1BLz5S42jBvkvh3giKDeP8K7ATRU+SIJoGH/32EuuXkiH2 A1VUpMkr7ZMVjPAWv5o8VVN0py89iS1+hqrijYHTh3Zq2xFCEVVz2ISd9UEh9QNI FAXzJVfvehAvNqqPHcmFLlNLE8BuloVZwOzcpwc3Q/n6fESdqkJ/EgFlimyn+a5G 1CqdlnLhqWr/qyYkGtlJraExsLrnE/ZPqHdIph4gF4gwVwFaBYoORvwXNQkSQTve pNmcx7vpC/ZfZR2J4JYkpohD8Di9tqWAGnk/4YvNw3r7V87U1sgP26BQjINSG35K Wx0uPqVfn1Xbli3AqNaT+0aIK9oAErNATv/+7wCjwMO3DsHlEPqO4noQl6J/wmbe 0atyCFN5E4rf876/eq26 =CU0o -----END PGP SIGNATURE----- --Sig_/Pbpkg1HB2Wc_wr=h_r9wD9q--