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 1JnICA-0005TU-DA for garchives@archives.gentoo.org; Sat, 19 Apr 2008 18:53:54 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AF28BE07AB; Sat, 19 Apr 2008 18:53:52 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 646CFE07AB for ; Sat, 19 Apr 2008 18:53:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id E7C8F668D6 for ; Sat, 19 Apr 2008 18:53:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -2.922 X-Spam-Level: X-Spam-Status: No, score=-2.922 required=5.5 tests=[AWL=0.677, 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 9movBk0CnFiW for ; Sat, 19 Apr 2008 18:53:40 +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 29059654A5 for ; Sat, 19 Apr 2008 18:53:39 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JnIBp-0006Io-RU for gentoo-dev@gentoo.org; Sat, 19 Apr 2008 18:53:33 +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 ; Sat, 19 Apr 2008 18:53:33 +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 ; Sat, 19 Apr 2008 18:53:33 +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: Sat, 19 Apr 2008 18:53:27 +0000 (UTC) Message-ID: References: <20080419053116.50e0ffe6@snowcone> <20080419044512.GD29470@supernova> <20080419055420.29ab56e1@snowcone> <20080419052720.GE29470@supernova> <20080419063300.6d2a2525@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=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: aa553146-264f-4460-a710-ee9a47956131 X-Archives-Hash: 47b978ac081c8ceadfd956830819a35a Ciaran McCreesh posted 20080419063300.6d2a2525@snowcone, excerpted below, on Sat, 19 Apr 2008 06:33:00 +0100: > On Fri, 18 Apr 2008 22:27:21 -0700 > Donnie Berkholz wrote: >> My interpretation is pkg_* counts as runtime (I can imagine a package >> wanting to run itself at this point), so packages in RDEPEND should be >> usable at that point. >=20 > Which would be fine, except it makes the tree unusable. >=20 >> Really, it seems to be an additional type of dependency that neither >> DEPEND or RDEPEND fully describe, and this DEPEND+RDEPEND idea isn't >> quite capturing it either. >=20 > Yup, and for future EAPIs labels can fix this. But we have to have a > sound solution for current EAPIs. It seems to me that at least for current EAPIs, RDEPEND simply cannot be=20 depended upon during pkg_*inst without breaking things. I can't see a=20 way around that. About the least-bad of multiple bad solutions I can see for Donnie's=20 conceivable run scenario would be to print a message in pkg_postinst=20 telling the user to run emerge --config before running the program=20 normally, maybe even going to the point of renaming the runtime and=20 installing a fake that reminds folks to run emerge --config first, if=20 it's critical enough. (pkg_config would then kill the fake and rename=20 the runtime back to its proper name.) Now consider binary packages. DEPEND can't be used as-is, which in the=20 OR case would then mandate RDEPEND and again result in broken behavior=20 due to circular dependencies, so that simply doesn't work. That leaves=20 the intersection of both DEPEND and RDEPEND sets as the only possible=20 logically consistent resolution... UNLESS we either (1) accept that binary package behavior simply can't be=20 correctly defined under current EAPIs and declare it an indeterminate=20 legacy exception, or (2) declare binary packages an exception that works=20 by different rules, and then define them (somehow). Either alternative=20 would then leave somewhat more flexibility for the ordinary build case,=20 presumably enough to reasonably accurately describe current behavior=20 deterministically. (I'll freely admit to not knowing enough about=20 current tree behavior to pick the right option there.) --=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