Re: Summary of implicit DEPENDS problem

[Greg Troxel <gdt%lexort.com@localhost>]

Jonathan Perkin <jperkin%mnx.io@localhost> writes:

>>I don't quite follow this from your email.  It sounds like
>>IMPLICIT_DEPENDS is something that is a full dep of something that is a
>>full dep, and IMPLICIT_BUILD_DEPENDS is a full dep of something that is
>>a build dep.  Things that are build deps only of either are not
>>relevant.  Is that what you mean?  (I'm not at all sure I got that
>>right.)
>
> Yes.  An implicit dependency is anything .include'd in a buildlink3 of
> a direct dependency.  IMPLICIT_DEPENDS are those where the top-level
> bl3 DEPMETHOD is "full", IMPLICIT_BUILD_DEPENDS where they are
> "build".  For completeness sake there is also the chance that a
> top-level bl3 is set to "full" but along its tree a DEPMETHOD is set
> to "build", in which case that dep (and its children) will be
> IMPLICIT_BUILD_DEPENDS.
>
> Ultimately they should be effectively the same as DEPENDS and
> BUILD_DEPENDS, which is why I chose the same nomenclature, but are
> implicit rather than explicit.

Thanks; I understand now.

I don't like "implicit" as that means "not stated", and these are
manifest in pkgsrc sources, just not in the original package.  So this
sort of feels like "recursive" except that it isn't recursive, or at
least I hope not.  I would therefore suggest CHAIN_DEPENDS or
NESTED_DEPENDS.