In article <Pine.NEB.4.61.0410091306240.6645@server.duh.org>,
	tv@duh.org (Todd Vierling) writes:
> On Sat, 9 Oct 2004, Thor Lancelot Simon wrote:
> 
>> I think it would make sense to be a little more careful about recording
>> higher dependency versions than necessary in Makefiles, but also to record
>> the dependency in the *built binary package* as the actual version linked
>> with, or higher, not the dependency version given in the Makefile.
> 
> That's actually the point of @blddep, which already exists in +CONTENTS, but
> I don't think it is used to this extent just yet.  (It currently lists an
> explicit version, not a dewey, and is not enforced.)

I seem to recall arguing for that before we were doing PKGREVISION bumps
for ABI changes in dependencies.  My idea was, that if a user complained
of a missing library, we could ask him the output of (what is now)
"pkg_info -N" and figure out what went wrong.  I expected we would direct
the user to update a dependency manually, and also crank the dependency
in the package.

I do not think "pkg_add" should "enforce" @blddep, for the reason I just
posted in a parallel response to Thor's post.

Note, too, that there's still a fundamental issue with wildcard
dependencies, that none of our efforts, so far, addresses.  This is,
that the package really can't know, at creation time, in what ways that
its dependencies will evolve. In other words, the "upper limit" to the
wildcard can't be known.  I recall suggesting, that we collect the
"@needed" shared libraries in the "+CONTENTS" file, but I don't
remember what became of that.  It would required a trivial
modification to the "check-shlibs" target.  With that, "pkg_add" would
have all the information needed to install the correct dependency, or
complain if it weren't available.

-- 
Frederick