~> > So then when that package is installed on another box, it won't have
any
> > requirement for any curses (only ncurses in pkgsrc right now) -- and
> > possibly may not run (if the [n]curses is not installed).
> >
> > (Which is like gtexinfo not being registered as a DEPENDS for some
> > packages -- even thought install-info is clearly used in the
> > installation.)
>
> IMO, these things should go into the bootstrap kit for the OS. (So...
> now we need a portable NetBSD curses?) Same thing for openssl. There's
> no way we're going to be able to spot dependencies on things in our
> base system, and the chief advantage to having such things in our base
> system is that we don't then have to track dependencies.

Maybe for the packages (I listed in the first email) that have some type
of curses need, then do something like:

.include "../../mk/bsd.prefs.mk"
.if ${USE_NCURSES} == "YES"
.  include "../../devel/ncurses/buildlink2.mk"
.endif

For forcing an openssl dependency for apache2, for example, maybe have
some mk/bsd.pkg.defaults.mk DEPENDS_SSL setting. (And when that is
defined, then openssl will always be a DEPENDS for packages using the
security/openssl/buildlink2.mk.)

And for forcing a gtexinfo dependency for gmake, for example, maybe have a
mk/bsd.pkg.defaults.mk DEPENDS_TEXINFO setting that is used in
mk/texinfo.mk to define _NEED_TEXINFO.

With NetBSD the base collection is known, but building packages on one Red
Hat Linux box, for example, and then using on another Red Hat Linux system
may not work. Allowing the pkgsrc admin to force the dependencies will be
useful.

   Jeremy C. Reed
   http://bsd.reedmedia.net/