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 025E013877A for ; Mon, 28 Jul 2014 08:26:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DDD26E0EA4; Mon, 28 Jul 2014 08:26:40 +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 0FD76E0E28 for ; Mon, 28 Jul 2014 08:26:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 0AB3033FFDD for ; Mon, 28 Jul 2014 08:26:39 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -0.937 X-Spam-Level: X-Spam-Status: No, score=-0.937 tagged_above=-999 required=5.5 tests=[AWL=0.433, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9q08iOlxU0hi for ; Mon, 28 Jul 2014 08:26:32 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id BF5F733FEB1 for ; Mon, 28 Jul 2014 08:26:31 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XBgGJ-0005wx-66 for gentoo-dev@gentoo.org; Mon, 28 Jul 2014 10:26:27 +0200 Received: from epidot.math.uni-rostock.de ([139.30.30.47]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 28 Jul 2014 10:26:27 +0200 Received: from martin by epidot.math.uni-rostock.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 28 Jul 2014 10:26:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Martin Vaeth Subject: [gentoo-dev] Re: don't rely on dynamic deps Date: Mon, 28 Jul 2014 08:26:13 +0000 (UTC) Message-ID: References: <53CD6BED.10603@gentoo.org> <53CD8BBA.2010605@gentoo.org> <53D5072E.3030305@gentoo.org> <53D51311.1070802@gentoo.org> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: epidot.math.uni-rostock.de User-Agent: slrn/pre1.0.0-18 (Linux) 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 X-Archives-Salt: c246f2db-1c62-4d9b-8cfd-c2af2bf077c8 X-Archives-Hash: 9d949c93c19433337b55cda85be9ec19 Duncan <1i5t5.duncan@cox.net> wrote: > > 1) Foo incorrectly deps on bar > 2) User installs foo with the incorrect dep > 3) Foo maintainer detects the error > 4) Due to dynamic-deps, portage depcleans bar. > 5) Since nothing in the tree needs bar, it is removed. > 6) Finally, foo is removed from tree. > > ** User isn't ready to get rid of foo yet, but user's dep-tree just blew > up This is the problem of orphaned (without maintained ebuilds) packages: Both, dynamic and static deps break on the similar situation for different reasons. The above describes one problem which you get in this case with dynamic deps; to get a similar problem with static deps, you need a slightly different situation: 1-3 as above, 4 is skipped (due to static deps). 5) bar is split into bar-base and bar-gui. 6) as above (foo is removed from the tree). Now the static deps will keep in bar forever, omitting that the packages in the tree can install bar-base or bar-gui. The user's dep-tree blows up through blockers or merge conflict which cannot be resolved. I repeat once more: For packages no longer maintained in the tree, there is no secure way to treat them always correctly; "no longer maintained" means exactly this. Either the user should remove them, or he should take full responsibility by maintaining them by himself in his overlay. Choosing a strategy (dynamic or static deps) should not concentrate on users who refuse to choose this only reasonable solution - as excpected, they get a solution which works sometimes, but they have to keep the pieces when it breaks, no matter which strategy is decided. > What's worse, the usual trick of digging the ebuild out of vardb and > putting it in the user's overlay to shut portage up and let the user keep > foo doesn't work, because the vardb ebuild has an unsatisfied dep. This is not so bad: The user has to put a corrected ebuild into his overlay and must reemerge the package (currently, the latter could be skipped with dynamic deps). In fact, no matter whether you have static or dynamic deps, this is the only way to cleanly avoid the problems if you want to keep a package installed which is not maintained anymore: *You* must maintain it. There simply is no magic which can avoid this.