On Mon, 24 Oct 2005 21:37:03 -0700 Donnie Berkholz <[EMAIL PROTECTED]> 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 <headerB.h>" - 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
