Subject: Re: packages using ncurses
To: Julio Merino <jmmv@menta.net>
From: Johnny C. Lam <jlam@netbsd.org>
List: tech-pkg
Date: 02/20/2003 14:53:22
On Thu, Feb 20, 2003 at 08:56:40PM +0100, 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.
> 
> 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.
> 
> And here is the problem: That buildlink2.mk should be fixed to check if the
> system provides a native curses, and iff it doesn't, then unconditionally use
> ncurses (setting UE_NCURSES), so we get a dependancy.
> pkgsrc already handles situations like this one (with texinfo, for example).

No, the ncurses/buildlink2.mk file shouldn't be modified any further.  It
does exactly what it's supposed to do: add a dependency on ncurses when
functionality that can only be found in ncurses is needed.  If you'd like
to create some sort of pkgsrc/mk/curses.buildlink2.mk file that basically
looks like:

	.if !exists(/usr/include/curses.h)
	USE_NCURSES=	yes
	.  include "../../devel/ncurses/buildlink2.mk"
	.endif

and then include this file at the bottom of every package that requires
curses in some way, then you can do that.  This new file would do what
you want, which is to ensure that _some_ curses implementation is present,
though not necessarily ncurses.  It seems like you've made a start on
listing such curses-using packages, so please feel free to send-pr as a
change-request.

	Cheers,

	-- Johnny Lam <jlam@netbsd.org>