| 1 |
On Mon, 24 Oct 2005 21:37:03 -0700 |
| 2 |
Donnie Berkholz <spyderous@g.o> wrote: |
| 3 |
|
| 4 |
> The consequences of the two sides are like this, from what I can |
| 5 |
> see: |
| 6 |
> |
| 7 |
> 1) Headers are run-time and build-time deps |
| 8 |
> 2) Headers are build-time deps only |
| 9 |
|
| 10 |
Imho, that case fall under the concept of "exported deps" i had |
| 11 |
proposed some time ago, here: |
| 12 |
http://thread.gmane.org/gmane.linux.gentoo.portage.devel/750 |
| 13 |
|
| 14 |
Quickly summarized, the idea (for RDEPEND) was, for instance, the |
| 15 |
following: |
| 16 |
- pkgA installs libA.so, and depending on USE flag "flagB", it's |
| 17 |
libA.la file may contain "-lB". |
| 18 |
- thus, a pkgC linked to libA may also be linked to libB, but that |
| 19 |
depends on USE flags of pkgA, which can't be taken into account in |
| 20 |
pkgC's RDEPEND. In such cases, one simply can't write correct |
| 21 |
RDEPEND for pkgC. |
| 22 |
- the proposed solution was that pkgA.ebuild declares a |
| 23 |
EXPORTED_RDEPEND="flagB? ( pkgB )" variable. Evaluation of this |
| 24 |
variable ("pkgB" or empty, depending on whether flagB was set at |
| 25 |
pkgA compile time) would be stored in pkgA vardb metadatas, and |
| 26 |
packages RDEPENDing on pkgA would also automatically include this |
| 27 |
result in there RDEPENDs. Thus, pkgC would get correct RDEPENDs, |
| 28 |
depending how pkgA was compiled. |
| 29 |
|
| 30 |
Sure, the idea also applies for DEPEND (didn't talk about it in my |
| 31 |
initial RFC, but that's required anyway for the above example with |
| 32 |
libs explicitly linked through .la files). In the case of "headers |
| 33 |
including other headers", it would be as follow: |
| 34 |
- pkgA installs headerA.h, which has an "#include <headerB.h>" |
| 35 |
- since pkgA's binaries/libs don't need pkgB at runtime, it doesn't |
| 36 |
have an RDEPEND on this pkgB. But it should EXPORT_DEPEND="pkgB". |
| 37 |
- pkgC, which has a DEPEND="pkgA", would then automatically import |
| 38 |
a DEPEND on pkgB. |
| 39 |
|
| 40 |
Now, that's just a vague idea of portage improvement. Not sure how |
| 41 |
good/bad it is, but anyway it's not something that would be |
| 42 |
available anytime soon. And until something like that is possible, |
| 43 |
i tend to agree Spider that cluttering RDEPENDs is the less worst |
| 44 |
one can do to make things work. |
| 45 |
|
| 46 |
-- |
| 47 |
TGL. |
| 48 |
|
| 49 |
-- |
| 50 |
gentoo-dev@g.o mailing list |
Archives