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 5C5C413877A for ; Tue, 22 Jul 2014 19:26:09 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 092D8E0F69; Tue, 22 Jul 2014 19:26:05 +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 18583E0F5D for ; Tue, 22 Jul 2014 19:26:04 +0000 (UTC) Received: from pomiot.lan (77-253-192-104.adsl.inetia.pl [77.253.192.104]) (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 2BA263400DF; Tue, 22 Jul 2014 19:26:01 +0000 (UTC) Date: Tue, 22 Jul 2014 21:26:04 +0200 From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= To: "=?ISO-8859-2?B?UGF3ZbM=?= Hajdan, Jr." Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] don't rely on dynamic deps Message-ID: <20140722212604.3126f177@pomiot.lan> In-Reply-To: <53CE11F9.8020700@gentoo.org> References: <53CD6BED.10603@gentoo.org> <53CD8BBA.2010605@gentoo.org> <53CE11F9.8020700@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.24; 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_/veT_5tbwD+QZx_aLPhkabp7"; protocol="application/pgp-signature" X-Archives-Salt: e7dde859-d498-4b95-9475-f6ec04185328 X-Archives-Hash: 754e91d68c2671cdf4bbe88621934e15 --Sig_/veT_5tbwD+QZx_aLPhkabp7 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Dnia 2014-07-22, o godz. 09:25:45 ""Pawe=B3 Hajdan, Jr."" napisa=B3(a): > On 7/21/14, 11:52 PM, Alexander Berntsen wrote: > > Micha=B3 has documented the shortcomings of dynamic deps in our wiki[0]. > > (Thank you!) This documentation also includes two of our possible > > solutions. > > > > [0] =20 >=20 > Thank you, this is very useful. I didn't understand the issue much > before reading that page. >=20 > One question: why for "Removal of a USE flag along with the relevant > dependencies" dynamic deps say "revbump + unnecessary rebuild"? What > would happen without the revbump? Well, for completeness I'll start by listing what would happen with static deps. Though nothing will actually happen. Already-built packages may have the flag enabled along with deps. When people rebuild -- through --newuse, --changed-use or otherwise -- they will get the functionality and dependencies removed along with the flag. How dynamic-deps would handle that are pretty much a matter of implementation choice. I can think of two major possibilities: 1. dynamic-deps are applied nevertheless. Since the relevant dependencies are removed along with the flag, dynamic-deps causes portage to no longer pull in needed libraries even though package was built with the flag enabled and still links to them. Long story short, linkage is broken. 2. PM notices IUSE no longer matches and doesn't apply dynamic-deps. While this prevents the breakage from happening, it's one additional point to the list of cases when dynamic-deps are disabled. Which means that no further dependency changes to the ebuild have dynamic effect and -- with current portage implementation -- the dependencies are 'reverted' to the state when the package was installed, even though just before the change portage used ebuild dependencies. Of course, you could try to invent some smart logic that would handle this specific case better. But it makes the dependency resolution even more complex and hard to understand, plus someone needs to actually do it. And then, you're going to hit even more corner cases and implement additional workarounds for each one. And then each of those workarounds will create new corner cases... --=20 Best regards, Micha=B3 G=F3rny --Sig_/veT_5tbwD+QZx_aLPhkabp7 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJTzrrMXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZOZl0QAODmx8Fge5Fn5bvPMGaeCibO AC7mY/wVe2kj6SvZnUDxqnhnA8aiwSyYM2xVxa/SyrJtFRBJSnV/XMxPzoLHtfPg ZzCCDp1AJoQ3yp1Qr2OFjqG+PWQhUc7j4G+kIgsX+dWWq8J/OaQO2t79jvGlRMtz oHALiiSzgvuZAsNvN6iAtDT/NaDlu3V+F7se9muK7KS5ma9Jfgjn07eHKJKiqoGJ yZLNklWxV9Ne8FrTFZhHsTH80Zs5jtmZcDk9Hp+S9xihA6FKrTCViiMnjQlbPi3I aGHOdwz+kah45sJyKShkMYl4RL9z1OXTlVLpeP97I2eI1F6DaSv0wcCdSZmoaFRT 3AZDf6K4b0J15xasBZ/fb0Tit8CHpL43Nk+jaLE1iiODA4lUxMlIW6AnhkOjEe33 57DkrZ+pBHmJlPamJPnIwcd5tEB7H5/xRKJzfkC/tAlUNOYUKmz+9rYmHW5j6x4p hLyO0oUMsOhLuyt9YZHMu51BaFDxJLVMliyXcgz0c0PIS1vFhnHPRjjxRdhYEV/S oH2AJw9HecUcFonVztxRaEtpxGqPLcd3V1F61YUuD8HCC7oFQRlzVxCC75mwf2Yu Cwa/wmqetMs3tXiOQHsM2xy4khcOu9hUzOYeMAxhYT/yFBJ5DaAi/Tn4pNMWtQ0m ABsK0bqeiAD2mVOJ7mu/ =7EOK -----END PGP SIGNATURE----- --Sig_/veT_5tbwD+QZx_aLPhkabp7--