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 3EABB138A2F for ; Fri, 25 Jul 2014 08:39:25 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6F85EE15CC; Fri, 25 Jul 2014 08:39:20 +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 693DFE15B6 for ; Fri, 25 Jul 2014 08:39:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 6F70D34009D for ; Fri, 25 Jul 2014 08:39:18 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.506 X-Spam-Level: X-Spam-Status: No, score=-1.506 tagged_above=-999 required=5.5 tests=[AWL=-0.803, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 7PAU8Vwg-tlH for ; Fri, 25 Jul 2014 08:39:09 +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 92DFB3400A3 for ; Fri, 25 Jul 2014 08:39:09 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XAb1s-0004Np-MB for gentoo-dev@gentoo.org; Fri, 25 Jul 2014 10:39:04 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Jul 2014 10:39:04 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Jul 2014 10:39:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: don't rely on dynamic deps Date: Fri, 25 Jul 2014 08:38:53 +0000 (UTC) Message-ID: References: <53CD6BED.10603@gentoo.org> <201407212153.04605.dilfridge@gentoo.org> <20140721205527.142cb3d5@googlemail.com> <1405976767.1013.9.camel@gentoo.org> <53CE6CED.1060300@gentoo.org> <21454.45733.912584.800633@a1i15.kph.uni-mainz.de> <21454.47827.725294.211687@a1i15.kph.uni-mainz.de> 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: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT d447f7c /m/p/portage/src/egit-src/pan2) X-Archives-Salt: 57cec1f4-8f95-4d13-a828-3aee591b1312 X-Archives-Hash: fd3d5c14991200ada4a04b0ebbfc562c Rich Freeman posted on Tue, 22 Jul 2014 21:15:01 -0400 as excerpted: > On Tue, Jul 22, 2014 at 4:06 PM, Martin Vaeth wrote: >> ...but by introducing all the additional complications Ian has >> mentioned. More precisely: What happens if new dependencies are >> introduced which are not satisfied? >> One has to face it: Portage must not just silently "update" the >> database and thus silently produce a /var/db which does not satisfy its >> own dependencies... > > While this is problematic, I think portage actually can handle this (but > I haven't tested this recently). Portage already allows you to clean a > package without its reverse deps leading to a system in exactly the > state you describe. I believe portage will just try to bring the > package back at the next emerge @world (or any other set containing the > reverse dep). FWIW I tested this with a number of packages just the other day while doing an initial test-build of qt:5 and kde:5 from the relevant overlays. Various kde-workspace5/plasma5 packages can't coexist with the kde:4 versions, but I didn't want to remove the kde:4 revdeps or set- elements from my installed sets until I was sure the kde:5 versions worked fine. Apparently the kwin:5 version I was testing doesn't like my radeon turks (hd6670 IIRC) hardware their current v3.16-pre kernel drm drivers as once I had the whole setup installed and tried to startx with it, kwin ended up in a segfault/respawn cycle, so my surgical unmerge of specific kde:4 packages was just as well, making it relatively easy to simply emerge -k @world and get back to a working system from the binpkgs, automatically unmerging the kde:5 blockers on the way since I hadn't actually let portage put them in @world just yet. Yes, a simple emerge --deep @world pulls everything missing but needed back in, so that bit of portage at least seems to be working just fine. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman