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 9112C1387FD for ; Tue, 1 Apr 2014 05:54:37 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3AA2CE0AD3; Tue, 1 Apr 2014 05:54:21 +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 3813CE0A8E for ; Tue, 1 Apr 2014 05:54:20 +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 EE1C033FCED; Tue, 1 Apr 2014 05:54:17 +0000 (UTC) Date: Tue, 1 Apr 2014 07:54:11 +0200 From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= To: gentoo-dev@lists.gentoo.org Cc: blueness@gentoo.org Subject: Re: [gentoo-dev] Stable masks on multilib packages Message-ID: <20140401075411.2e71b0fa@pomiot.lan> In-Reply-To: <5339F5B8.8000305@gentoo.org> References: <20140401001617.42fdc3bc@pomiot.lan> <5339F5B8.8000305@gentoo.org> 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_/hxw2XjUZ81Ug4d0+ElH=peq"; protocol="application/pgp-signature" X-Archives-Salt: 630a8607-4745-467e-9eda-cd2bf58a23b3 X-Archives-Hash: 497fc8706d45e5c5630e19422fe37691 --Sig_/hxw2XjUZ81Ug4d0+ElH=peq Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Dnia 2014-03-31, o godz. 19:09:44 "Anthony G. Basile" napisa=B3(a): > On 03/31/2014 06:16 PM, Micha=B3 G=F3rny wrote: > > 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. > I'm not sure exactly what you mean here --- where/how does this global=20 > stable masking happen? Right now you have a bunch of maskings of=20 > abi_x86_32 on various packages in arch/amd64/package.use.stable.mask but= =20 > not on any other arches where you just have the use.mask/use.force=20 > combination. Are you going to migrate the amd64 file to other multilib=20 > arches and mask non-native abis? Like on mips64el/multilib/n32 would=20 > you be masking abi_mips_o32 and abi_mips_n64 for all those packages? The new solution would be base/package.use.stable.mask that would mask all of multilib on all stable arches, on this long list of packages. So, not only the two ABIs but all of them. Which would effectively make ebuild behave like it had no multilib at all. > > Your thoughts? >=20 > How does this "go live" once these flags are enabled? Do you just=20 > remove the global mask all at once? That sounds a bit scarier than just= =20 > removing the masks one package + deps at a time. (Maybe a non-question=20 > because I'm still now sure how this masking works.) Something like this, yes. Once all packages are migrated and some time passes, we unmask all the flags locally and do a repoman run. We find out what needs to go stable, report bugs, wait and repeat. Then we do a second stabilization request, this time for testing the tree (mostly emul-linux replacement) with multilib enabled. Once arch teams are done testing, they remove the stable masks for particular ABI. When all reverse dependencies are fixed to use || () deps instead of emul-linux (and rev-bumped) we can move away from emul-linux through the usual procedure of last rites with a proper announcement. This is likely the most fragile step of all but we will do our best to make it as simple as possible, and I think our users can handle that. > Also, I don't see that it should be an issue, but do you think this=20 > might affect catalyst runs --- I have to ask because=20 > repairing/reconfiguring seeds is a lot of work. Well, I think this mostly depends on whether you want multiple multilib ABIs in stages -- or if you assume that the toolchain is enough, and people will build other ABIs as they need. Though I think that once toolchain switches to abi_* flags (vapier seems to show interest in that), we will use.force the necessary ABIs on it and its dependencies, so there should be no explicit need for change. However, I guess the toolchain changes will be sent out for testing anyway, so releng can check first hand. --=20 Best regards, Micha=B3 G=F3rny --Sig_/hxw2XjUZ81Ug4d0+ElH=peq Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQJ8BAEBCgBmBQJTOlSDXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZOpAUP/1DlLnAwHX0HkGnq17+hDOAh 3rFF2lflwXhQ3TnXNXlUa6cERmX+sHOQymRWg5FRql827+QuGmbxm0TWbLqCXST0 6aZWrR1GfBKi1/VIXZ7KtL5zeNYBaZyZYVWymALVO399qLpCgW1oL/446X5ip6bw NT8bmO6iJv/2tykqiuKRxedoMCExkgJ5/A3jwlVe2iTyGMaxVSlzrdr0HntweyGW KYOIk8fBq5vTPwioL2W7hmgBVhMuYi0+ziSextFPIa91pCQT7RPLCCsvWMAyopjz l6lWzXAo3Voo9+FIq0oJ4Vr95z5Ru51fcaLXV1eZoJfPlweqnlZVxyG2wxJmpwMd VZ2XWAEPD8rNAFjfQ+sywlGOhy42aJ0J3cAUvDUIeEsihqHSIqKyQhEABVSjj6LI o1iCBqMP9V7Gc6LpadPiSZ5NJ87WUISnnJBCEmdxJTQ2LkxI+ElMa617HlXbh7IX frrZNMC4JD8SSfL6r3wLlc2kSlO6PoUkQdDM0FSNFSU9kWKfCvHd6b1k68PWMobw x4gmtactwVdyHRzNuKzttCxWhNIDnBA2jYTBgqmTMgEg2FFmp4hzrsRYWNoVz9TG EcA+RDouzFEq/VKTIRWI93dr3s0EvFBCSJQDF2Db38Nr+17hKguGbD7/rnJwGBjc bTMEE79usJ9X/1y/i2/Y =eqYq -----END PGP SIGNATURE----- --Sig_/hxw2XjUZ81Ug4d0+ElH=peq--