| 1 |
On Tuesday 19 August 2008 21:35:35 Steve Long wrote: |
| 2 |
> Not really fussed about how it's resolved, so long as we get some sort of |
| 3 |
> correct link dependency information (which compile-against is not.) |
| 4 |
|
| 5 |
compile-against is designed mainly for packages that include each-other's |
| 6 |
headers, nothing to do with linking. For example, some libX11 headers |
| 7 |
include xproto headers. If a given package only contains a reference, say, |
| 8 |
<X11/Xlib.h>, and not anything from xproto, then it should only build-depend |
| 9 |
on libX11, but xproto still needs to be present at compile-time. The only |
| 10 |
way to represent that currently is by making libX11 RDEPEND on xproto, |
| 11 |
meaning "libX11 is not fully-functional unless xproto is installed", but |
| 12 |
embedded people and the like would prefer something more fine-grained, |
| 13 |
effectively splitting the idea of "fully-functional" into "fully-functional |
| 14 |
at runtime" and "fully-functional at build-time". |
| 15 |
|
| 16 |
What exactly do you mean by "link dependency information"? How would you like |
| 17 |
the package manager treat a "link" dependency differently from any other |
| 18 |
build dependency? |
Archives