On 4 Feb 2000, Martin J. Laubach wrote:

>   Something completely different -- I have noticed that more
> and more packages include everything and the kitchen sink, which
> makes them difficult to use in normal situations. For example,
> webalizer (a httpd log analyzing tool, usually run on the web
> server), depends on png (ok), on freetype (huh?) which depends
> on gettext, and on xpm which depends on X11.
> 
>   So that package is not buildable/useable on systems without
> X11, which is what web servers often are. Isn't all that "let's
> turn on all the options and depend on everything in sight" going
> a bit overboard?

On the other hand, if none of the "goodies" work as installed, if the
package system leaves the user with an incomplete install where
nothing quite works, he'll be tempted to not bother with the package
system at all.

I've been mulling over a proposal to undeprecate RUN_DEPENDS, and
especially enable a make option to skip over them at build time, and
a switch to pkg_add to optionally ignore them. pkg_create should
still record them, whether they're actually installed or not.

This would only be for when the presence of the dependency wouldn't
affect the build either way. Cases where the _build_ is affected by
the presence of another package would have to be handled with build
options or by forking the package, as they are now. Examples of the
former: xli, xpman, rplay for afterstep-current; htdig for wwwoffled;
also perl, python, Tcl for the many packages that install scripts.

For all these cases where the dependency is either called by a script,
or execvp()'d by name, build options are overkill. We could also save
ourselves the trouble of reinstalling the dependency every time we
upgrade the depending package. That's why the change would have to be
made to pkg_create to record the RUN_DEPENDS _after_ the depending
package is installed.