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 1JntAq-0005RT-Bo for garchives@archives.gentoo.org; Mon, 21 Apr 2008 10:23:00 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 94875E0474; Mon, 21 Apr 2008 10:22:57 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 42190E0474 for ; Mon, 21 Apr 2008 10:22:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id ECD9967343 for ; Mon, 21 Apr 2008 10:22:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -2.919 X-Spam-Level: X-Spam-Status: No, score=-2.919 required=5.5 tests=[AWL=0.680, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 FsiUcmceH1G4 for ; Mon, 21 Apr 2008 10:22:49 +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 8773367325 for ; Mon, 21 Apr 2008 10:22:47 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JntAV-0004C3-5Z for gentoo-dev@gentoo.org; Mon, 21 Apr 2008 10:22:39 +0000 Received: from ip68-230-99-4.ph.ph.cox.net ([68.230.99.4]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Apr 2008 10:22:39 +0000 Received: from 1i5t5.duncan by ip68-230-99-4.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Apr 2008 10:22:39 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: Dependencies that're available at pkg_*inst Date: Mon, 21 Apr 2008 10:22:33 +0000 (UTC) Message-ID: References: <20080419053116.50e0ffe6@snowcone> <20080419044512.GD29470@supernova> <20080419055420.29ab56e1@snowcone> <20080419052720.GE29470@supernova> <20080419063300.6d2a2525@snowcone> <20080421051727.GA10765@comet> 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 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-99-4.ph.ph.cox.net User-Agent: Pan/0.132 (Waxed in Black) Sender: news Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 193938b1-e8fb-4bbe-ad9a-cc291ec08b20 X-Archives-Hash: 4383257bc7156f811d0d6457deb047db Donnie Berkholz posted 20080421051727.GA10765@comet, excerpted below, on Sun, 20 Apr 2008 22:17:27 -0700: > I guess the RDEPEND+DEPEND case would save an ebuild dev the work of > specifying the COMMON_DEPEND list, but other than that, I can't think o= f > any benefits. It would force both RDEPEND and DEPEND to be installed fo= r > binpkgs, which sucks. If I read the original proposal correctly, it's not proposing a simple +,= =20 that BOTH RDEPEND and DEPEND be guaranteed installed at pkg_*inst, IOW by= =20 set theory, not the UNION of the two sets, but the INTERSECTION of the=20 two sets, that is, packages that appear in both lists at once, not those=20 appearing in one XOR the other. Thus a COMMON_DEPEND would still be useful as it would be the list=20 appearing in both (thus effectively the list necessary for pkg_*inst,=20 same as the OR case). Both lists could still exclusively include=20 packages, and packages not listed in DEPEND only would not have to be=20 installed for binpkgs. So it's not OR vs AND, but OR vs INTERSECTION. As I stated in my other post, RDEPEND alone can't be used without=20 breaking things. That applies to binary package installation as well,=20 where DEPEND along can't be used either as that would require=20 installation of unwanted packages. Thus, the OR case doesn't seem to=20 work for binary installation at all, since neither RDEPEND nor DEPEND can= =20 be relied upon alone, and the OR case proposes requiring at least one=20 complete set of the two be installed. Thus, for current EAPIs, the INTERSECTION alternative is the only=20 possibly working alternative if we are not to break binary package=20 support and not force full DEPEND installation on binary targets. It's=20 not ideal as it'll potentially force unwanted and otherwise unnecessary=20 package installation on both the build-host and the binary target, due to= =20 fact that it forces pkg_*inst dependencies into both DEPEND and RDEPEND,=20 but IMO it's better than forcing the whole set of DEPENDs to be installed= =20 on binary targets, which would be the only working alternative in the OR=20 case above. As others have said, this is certainly a good candidate for future EAPI=20 change, but it's not future EAPIs under current discussion, so that fact=20 doesn't help the current discussion. --=20 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 --=20 gentoo-dev@lists.gentoo.org mailing list