On Thu, 20 Feb 2003, Julio Merino wrote:

> On Thu, 20 Feb 2003 10:34:34 -0800 (PST)
> "Jeremy C. Reed" <reed@reedmedia.net> wrote:
>
> > > 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
>
> Why do you need this?? Simply include the ncurses/buildlink2.mk file directly
> and let buildlink2 do its magic.

How is that any better than simply including ncurses/buildlink2.mk in
the package's Makefile?

> If the system has a "native" curses, then it will be used and no dependancy
> will be registered. If the package requires ncurses (won't work with curses),
> then the ncurses package will be installed independantly of your system.

The problem is, how do you know which packages depend on curses, or
openssl, or gettext, in order to get this imaginary dependency?

The system you describe is fully in place for openssl, and yet, hidden
dependencies go undetected for years. I think we'd be doing non-NetBSD
pkgsrc users a better service if we just said, "You need these things
to run NetBSD pkgsrc, and that's that."

Frederick