From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1JqLRU-0001kC-7m for garchives@archives.gentoo.org; Mon, 28 Apr 2008 04:58:20 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5715EE0300; Mon, 28 Apr 2008 04:58:18 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 05A7EE0300 for ; Mon, 28 Apr 2008 04:58:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id B5ABB673D6 for ; Mon, 28 Apr 2008 04:58:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -0.636 X-Spam-Level: X-Spam-Status: No, score=-0.636 required=5.5 tests=[AWL=0.896, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 dSyGyD-22kTd for ; Mon, 28 Apr 2008 04:58:11 +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 EC73167406 for ; Mon, 28 Apr 2008 04:58:08 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JqLRF-0001gT-Oq for gentoo-dev@gentoo.org; Mon, 28 Apr 2008 04:58:05 +0000 Received: from 91.84.165.251 ([91.84.165.251]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 28 Apr 2008 04:58:05 +0000 Received: from slong by 91.84.165.251 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 28 Apr 2008 04:58:05 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steve Long Subject: [gentoo-dev] Re: Re: Dependencies that're available at pkg_*inst Date: Mon, 28 Apr 2008 05:57:04 +0100 Message-ID: References: <20080419053116.50e0ffe6@snowcone> <480A1FEE.4020604@gentoo.org> <20080420005728.2d4d2c70@snowcone> <20080427115556.13667557@snowcone> 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=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 91.84.165.251 User-Agent: KNode/0.10.9 Sender: news X-Archives-Salt: 118f46b0-10ac-4aa8-8880-373dc1e4dfd0 X-Archives-Hash: 45563bd6f8c7beeeb3a60a85dd255ad2 Ciaran McCreesh wrote: > On Sun, 27 Apr 2008 10:41:57 +0100 > Steve Long wrote: >> Use PDEPEND. > > PDEPEND has a different meaning, and isn't suitable for runtime > dependencies. > "PDEPEND should be avoided in favour of RDEPEND except where this will create circular dependency chains."[1] Sounds very much like it is used for runtime deps, and breaking RDEPEND cycles has often been given as its purpose in #-portage and #-dev-help, as well as in the devmanual. >> While I like labels they need to be discussed more on-list as well as >> on bugzilla (it's not reasonable for you simply to advertise them and >> then close down discussion.) For instance, there is no reason >> everything has to be loaded into just one extant metadatum, not do >> they preclude new metadata (such as a SRC_DEP here.) > > Labels can be discussed on-list whenever there's a chance in hell of > Portage implementing any non-trivial new features. > That's not exactly in the spirit of collaboration (nor are your continuous snipes at portage.) New features should be discussed with a wider audience than bugzilla, not just used to advertise one impl and slipped in via an overlay. Further, having a consensus would allow pkgcore to move ahead with a more solid spec, and that /is/ conducive to quicker implementation in portage, since those two teams do know how to collaborate effectively. > Anyway, I'm going with the second wording in the original email. > Of everything suggested, only > the two original wordings are correct, and of those two, the second is > better defined. > 2b) seemed better. With use of PDEPEND in the manner outlined, it simply means pkg_{pre,post}inst can't rely on the PDEPEND'ed pkgs, only those in RDEPEND. Build-time dependencies wouldn't appear to cover the use-cases brought up, nor are they relevant for binary installs. I can see how it would be easier for the PM to be able to go for one or the other, but it doesn't give an ebuild author a consistent base. The intersection does but doesn't allow a package to call itself (one of the use case brought up.) PDEPENDs are used at ebuild authors' discretion aiui, and in collaboration between the two maintainers: that judgement would seem to be useful to decide which interdependent package can call the other, which is very much dependent on the context. (A classic case of something that can't be solved automatically.) [1] http://devmanual.gentoo.org/general-concepts/dependencies/index.html -- gentoo-dev@lists.gentoo.org mailing list