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 A28D11387FD for ; Tue, 1 Apr 2014 15:12:07 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 62170E0A98; Tue, 1 Apr 2014 15:12:01 +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 64862E09C9 for ; Tue, 1 Apr 2014 15:12:00 +0000 (UTC) Received: from [192.168.1.195] (CPE002401f30b73-CM001cea3ddad8.cpe.net.cable.rogers.com [99.224.181.112]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: axs) by smtp.gentoo.org (Postfix) with ESMTPSA id 44B6733FB2C for ; Tue, 1 Apr 2014 15:11:59 +0000 (UTC) Message-ID: <533AD74B.3080508@gentoo.org> Date: Tue, 01 Apr 2014 11:12:11 -0400 From: Ian Stakenvicius User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Stable masks on multilib packages References: <20140401001617.42fdc3bc@pomiot.lan> In-Reply-To: <20140401001617.42fdc3bc@pomiot.lan> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit X-Archives-Salt: 9e3574d3-edaa-4f89-b417-0869dde0d549 X-Archives-Hash: 5d830e553f159249d23fb61bb2734ab1 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 31/03/14 06:16 PM, Michał Górny wrote: > 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=abi_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? > ... how messy is this going to be on current systems, if implemented? This -is- going to cause use flag changes on a whackload of packages, which at minimum I expect means a bunch of needless rebuilds. I think it's probably best to keep with the current path, and just hurry up the migration on x86. If we switch to masking all abi_*_*'s, then not only do we rebuild a whackload of packages now, but we also end up rebuilding them again when we remove the abi_*_* mask, -even if- the alternative abi's aren't needed. A note on #3: if MULTILIB_USEDEP -isnt- working on other PMs, i hope we have bug reports and we should work to resolve those ASAP or abandon the project/find a different solution. We're over a year into it though (i think?) so i expect it's fine since I don't remember hearing of any issues yet... on a side note, to follow up -- when we do remove the masks, what're the thoughts on perhaps changing the multilib profile on amd64 to auto-enable abi_x86_32 flags on some packages? Indeed, if the toolchain is converted to multilib-build, would this be enough to differentiate between amd64-multilib and pure64? (bootstrapping may of course still be a problem if users are trying to switch, but probably not any more of a problem than it is right now, right?) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlM610sACgkQ2ugaI38ACPAPoQD/TpzYLaAwLiRBSVLRII/lI1OK fN9hOQ8wvMaHoKfuHK4A/RmUtt1G7k8HEsAhsMSWAYFUd0KdlbEd4snhcxaR6W+M =n7yQ -----END PGP SIGNATURE-----