Alright, on the different kinds of dependencies, let me see if I get
this straight.  Please correct me where I'm wrong, and sorry for being
overly verbose:


Currently, we have BUILD_DEPENDS[1] and DEPENDS.  BUILD_DEPENDS, as the
name suggests, is only required when actually building the package.
That is, when we install a binary package, BUILD_DEPENDS are not pulled
in, their absence is irrelevant.

DEPENDS contains packages that are absolutely mandatory for this package
to function.  The package will not build nor work without DEPENDS.  That
is why DEPENDS are built _before_ the actual pacakge -- if the DEPENDS
fail for whatever reason, there is no point in trying to build the
package itself.  Naturally, when installing binary packages, pkg_add
complains if the DEPENDS are not found.


Now what we have been discussing here suggests that there are some other
variations of dependencies.

Hubert pointed out the case of a package automatically being built in a
different way if it finds a certain other (non-DEPENDS) package,
creating an implicit DEPENDS.  This is dangerous as pkg_delete does not
complain about the implied DEPENDS package being removed, when in fact
this breaks the original package.  Additionally, when creating a binary
package on a system with the implied dependency, the package will not
function on a system without, yet pkg_add does not complain about the
missing package.  Let's call this "Problem 1".

A package may depend on the existence of a functionality provided by
various different (and possibly among themselves conflicting!) packages.
That is, either one (or a combination) of these packages will allow the
package to be build and used.  It is impractical (possibly impossible)
to DEPEND on all of them.  Let's call this "Problem 2".

A package may want to point out that other packages are commonly used
together with this package.  However, it will build, install and work
happily without the other package.  Let's call this "Problem 3".


Problem 3 would easily be solved by a mechanism like SUGGESTS.  I do
feel that it is important that SUGGESTS are not turned into DEPENDS.
This would not make sense, as the original package does in fact work
equally well regardless of the presence of any SUGGESTS.  That is why
'make' should _first_ build the package and only after a successfull
build concern itself with any SUGGESTS.  Any SUGGESTS that, for whatever
reason breaks during building, must not prevent the initial package from
being installed.  Similarly, binary packages should not demand that
SUGGESTS are installed; pkg_add should simply, uhm, suggest them.  This
ensures that a package created from a tree that has any (or all) of the
SUGGESTS installed can be installed without a problem on a machine that
has none (or other) of the SUGGESTS.

Problem 2 is currently un-addressed.  It would obviously require
interaction from the user (or a variable that says "always install the
first of a choice of dependencies").  Once a choice has been made, that
choice becomes a de-facto DEPENDS, meaning that uninstalling it causes
that package to break.  The tricky part here would be to come up with a
mechanism that would allow substitution of one of the choice-depends,
that would allow a user to delete choice (a) iff one of the other
choices is installed.  Similarly, a binary package built using choice
(a) should be able to be installed on a machine that provides choice (b)
(or any other choice), while at the same time marking (b) as a
dependency for that package.  This sounds rather hairy.

Problem 1 could be solved by a different mechanism, maybe similar to
what I suggested as EXTRA_DEPENDS.  The point here is that if a package
(when built from sources) changes behaviour due to any possibly
installed libs, these libs become DEPENDS.  A binary package built
against these EXTRA_DEPENDS can *not* be installed on a system that does
not provide these libs, nor can the libs be removed.  Binary packages
that are uploaded to ftp should be built without any EXTRA_DEPENDS.


Even though it's just names, "RUN_DEPENDS" is, IMHO, not a good choice
for either solution, as it implies that the package does build, but not
"run" without it.  Other than that, I don't care what any of the
approaches is called.

Furthermore, I think that these three problems are different enough to
warrant separate solutions.

Now, what did I miss, overlook, misinterpret? ;-)

-Jan

[1] packages(7) also knows about FETCH_DEPENDS, but it is not known in
any of pkgsrc/mk/* ?

-- 
"Ford," he said, "you're turning into a penguin. Stop it."