David Leverton wrote:

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

I mean the dependency between the package in your example and libX11, or
between libX11 and xproto: what the programmer writes as a dependency in
the code. In certain cases the dependency does not actually matter (opaque
types) but it usually does, especially with C++. compile-against seems to
be derived from that information.

An ldepend would necessarily be a build-time depend. It would not
necessarily be a run-time depend (eg for plugins) although most pkgs
building from src with a USE flag pulling in the ldepend would rdepend on
the same pkg, if the flag is in effect at install time. OFC that's where
the soft dependencies (suggest, recommend) come into play.