On Mon, 22 Jul 2002, Jan Schaumann wrote:

> Frederick Bruckman <fredb@immanent.net> wrote:
>
> > What I would go for (and have suggested before), is reviving
> > RUN_DEPENDS for binary packages and such that *do* *not* affect the
> > build in any way, and a post-package stage to (optionally) install
> > them, and run the INSTALL scripts.
>
> I'm not familiar with RUN_DEPENDS, but the example Hubert gave does not
> seem to benefit from such a procedure, as a non-dependency has become a
> dependency in that case.  No?

No, it would not be appropriate for libraries, only cases where the
name of the executable is hardcoded in the binary unconditionally (no
configure test). E.g. "xp" and "asclock" for "wm/afterstep" (similiar
to your example regarding "blackbox"). If these were listed as
RUN_DEPENDS (or SUGGESTS, or whatever), "make
{extract,configure,build,install,package}" in "wm/afterstep" would
never install them, but "make {install,package}"  would add a key for
them to the "+CONTENTS" (e.g: "@pkgrundep"), so that a "pkg_add" of
the resulting package *would* install them by default. There's no need
for pkg_add to install them via "bin-install", either, so you'd need
an option to not install them for that use.

There used to be a RUN_DEPENDS, but it wasn't adequately distinguished
from DEPENDS, and it was removed. This would be different. The
important thing is, the package must be demonstratably able to build
without the (SUGGESTS or) RUN_DEPENDS installed. Thus, it applies to
your cases "2" and "4", but any attempt to apply it to "1" and "3"
would obviously fail (and that's a good thing).

Frederick