On Fri, 27 Sep 2002, Jeremy C. Reed wrote:

> I was guessing that "pkg_info -n" based its "Requires:" output on
> the currently installed packages.

We've talked about this on tech-pkg many times before, including
what's wrong with it, and where it should be changed. I'll spare the
list the full sermon, but please do review the mailing list archives.

> Why are some repeated? (Because many aren't.)

The problem, in a nut shell, is not that they're repeated, but that
they're sometimes wrong. "perl" today may be a meta-pkg of perl
modules, and tomorrow, a single package containing all the modules. We
need "perl" packages to depend on "perl", not "perl"'s components. The
structure of a required package should not be visible to the dependent
ones.

> Also, I think that @blddep is not a build dependency (like autoconf), but
> the actual package it was built with.

Yes, that's what it is.

> I am making a depencency database
> (as discussed earlier) -- so I am thinking I should use this actual
> @blddep information and not the "pkg_info -n" results or the @pkgdep. Any
> comments?

It's depends on what you're doing, exactly. If you're trying to
extract a consistent set from the blob, it would be safest to start
with the @blddep's, yes. You may still be able to update some packages
to newer versions, especially if their contents are the same. (Look at
the "lib/lib*.so.*" majors, or the "lib/lib*.so.*.*" files - the
dependencies are not always done carefully enough to be a good guide.)
Unfortunately, even the shared library versions can let you down, if
the author changes the ABI without a concommittent bump, which happens
surprisingly often.

Frederick