From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1IplcE-0004Dv-2P for garchives@archives.gentoo.org; Wed, 07 Nov 2007 14:10:46 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.2/8.14.0) with SMTP id lA7E9MCN031310; Wed, 7 Nov 2007 14:09:22 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by robin.gentoo.org (8.14.2/8.14.0) with ESMTP id lA7E7KBE028917 for ; Wed, 7 Nov 2007 14:07:20 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 87BA36577A for ; Wed, 7 Nov 2007 14:07:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -0.04 X-Spam-Level: X-Spam-Status: No, score=-0.04 required=5.5 tests=[AWL=0.492, BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZ6d6gZcru+6 for ; Wed, 7 Nov 2007 14:07:12 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id AF89865780 for ; Wed, 7 Nov 2007 14:07:11 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IplYR-0007vd-Tq for gentoo-dev@gentoo.org; Wed, 07 Nov 2007 14:06:52 +0000 Received: from 82.153.65.100 ([82.153.65.100]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 07 Nov 2007 14:06:51 +0000 Received: from slong by 82.153.65.100 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 07 Nov 2007 14:06:51 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steve Long Subject: [gentoo-dev] Re: EAPI feature suggestion: OBSOLETES (was: gentoo-x86 commit in profiles/updates: 4Q-2007) Date: Wed, 07 Nov 2007 14:09:50 +0000 Message-ID: References: <20071106161512.GA21625@aerie.halcy0n.com> <20071106210317.da2c9676.genone@gentoo.org> <20071106162335.482c6e4f@vrm378-02> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 82.153.65.100 User-Agent: KNode/0.10.4 Sender: news X-Archives-Salt: 7c8b3995-da9d-4f3a-a00e-497e833d1f27 X-Archives-Hash: 93ef4ea75076d2ff67d06d5c1b9b0797 Jim Ramsay wrote: > Whether or not 'move' was the correct action in the recent compiz > example, perhaps we need to consider that some times one package does > actually make another obsolete. The correct thing for the PM to > do is to first uninstall the obsolete package, then install the new one. > I don't think it was, for the reasons stated on the bug, and based on what Mr Mauch has just said. > Now, it has been my experience that blocking dependencies are currently > used to imply this "No, you have to remove cat/foo first before > installing cat/bar instead" situation. This is somewhat annoying for > me when I want to upgrade a bunch of packages, but I have to manually > uninstall a few blockers first before this is possible. > You can use a script to automate that [1] so it's just a question of pressing any key to unmerge (depending on the block; it might not actually apply by the time you come to the blocked app.) > This could be automated by the PM in those cases with some sort of > thing like this in the cat/bar-1.0.ebuild: > > OBSOLETES="cat/foo" > > Of course this would be a regular package atom (or list thereof), so it > could be tied to specific versions of cat/foo. > I really like that idea. (A RECOMMENDS thing similar to debian would be nice too.) > I suppose this could be seen as a special case of blocking deps which > would automate a specific "cat/bar is to be preferred over cat/foo" > > However, I'm not exactly sure what you would do if you have pkg1 which > depends on cat/foo and pkg2 which depends on cat/bar... > That kinda sounds like the same issue genone was raising; since the difference upstream is tied to a version, whereas the Gentoo package names apply to all versions there can be no guarantee of compatibility. Maybe you could get round this by only using versioned deps. (So a package move script would have to ensure nothing had an unversioned dep on either package.) [1] http://forums.gentoo.org/viewtopic-t-546828.html New, improved-- shiny! ;D -- gentoo-dev@gentoo.org mailing list