From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.50) id 1EUJca-0005kg-Ez for garchives@archives.gentoo.org; Tue, 25 Oct 2005 07:53:24 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id j9P7qgij027284; Tue, 25 Oct 2005 07:52:42 GMT Received: from corwin.easynet.fr (smarthost168.mail.easynet.fr [212.180.1.168]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id j9P7owiw016448 for ; Tue, 25 Oct 2005 07:50:58 GMT Received: from easyconnect2121138-64.clients.easynet.fr ([212.11.38.64] helo=eusebe) by corwin.easynet.fr with esmtp (Exim 4.50) id 1EUJaD-000728-CQ for gentoo-dev@lists.gentoo.org; Tue, 25 Oct 2005 09:50:57 +0200 Date: Tue, 25 Oct 2005 09:49:43 +0200 From: Thomas de Grenier de Latour To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Reminder on dependencies. Message-ID: <20051025094943.7706b624@eusebe> In-Reply-To: <435DB66F.9060807@gentoo.org> References: <1130199485.1413.3.camel@Darkmere.darkmere> <435DB66F.9060807@gentoo.org> Organization: Fasmz X-Mailer: Sylpheed-Claws 1.9.99-rc2 (GTK+ 2.8.6; i686-pc-linux-gnu) 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-Archives-Salt: d76060b1-a998-47aa-a020-fbf496060570 X-Archives-Hash: 9fad0bc1dd53fede456e7dd55fb47d56 On Mon, 24 Oct 2005 21:37:03 -0700 Donnie Berkholz wrote: > The consequences of the two sides are like this, from what I can > see: > > 1) Headers are run-time and build-time deps > 2) Headers are build-time deps only Imho, that case fall under the concept of "exported deps" i had proposed some time ago, here: http://thread.gmane.org/gmane.linux.gentoo.portage.devel/750 Quickly summarized, the idea (for RDEPEND) was, for instance, the following: - pkgA installs libA.so, and depending on USE flag "flagB", it's libA.la file may contain "-lB". - thus, a pkgC linked to libA may also be linked to libB, but that depends on USE flags of pkgA, which can't be taken into account in pkgC's RDEPEND. In such cases, one simply can't write correct RDEPEND for pkgC. - the proposed solution was that pkgA.ebuild declares a EXPORTED_RDEPEND="flagB? ( pkgB )" variable. Evaluation of this variable ("pkgB" or empty, depending on whether flagB was set at pkgA compile time) would be stored in pkgA vardb metadatas, and packages RDEPENDing on pkgA would also automatically include this result in there RDEPENDs. Thus, pkgC would get correct RDEPENDs, depending how pkgA was compiled. Sure, the idea also applies for DEPEND (didn't talk about it in my initial RFC, but that's required anyway for the above example with libs explicitly linked through .la files). In the case of "headers including other headers", it would be as follow: - pkgA installs headerA.h, which has an "#include " - since pkgA's binaries/libs don't need pkgB at runtime, it doesn't have an RDEPEND on this pkgB. But it should EXPORT_DEPEND="pkgB". - pkgC, which has a DEPEND="pkgA", would then automatically import a DEPEND on pkgB. Now, that's just a vague idea of portage improvement. Not sure how good/bad it is, but anyway it's not something that would be available anytime soon. And until something like that is possible, i tend to agree Spider that cluttering RDEPENDs is the less worst one can do to make things work. -- TGL. -- gentoo-dev@gentoo.org mailing list