Subject: Re: packages using ncurses
To: None <>
From: Jeremy C. Reed <>
List: tech-pkg
Date: 02/20/2003 10:34:34
~> > So then when that package is installed on another box, it won't have
> > 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/"
.if ${USE_NCURSES} == "YES"
.  include "../../devel/ncurses/"

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

And for forcing a gtexinfo dependency for gmake, for example, maybe have a
mk/ DEPENDS_TEXINFO setting that is used in
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

   Jeremy C. Reed