On Fri, Feb 21, 2003 at 10:48:46AM -0800, Johnny Lam wrote:
> It's because the name is important.  The other buildlink2.mk files were
> designed so that when you include it, you get what you're asking for.  I
> simply don't want to add complexity to the ncurses/buildlink2.mk file
> that don't have to do with ncurses at all because it makes for unexpected
> behaviour at times.  We've seen this already with the gettext-lib
> buildlink2.mk file.  I prefer the solution I suggested and was implemented
> in pkg/20453 if only so that packages that include ncurses/buildlink2.mk
> _know_ that they're getting a ncurses implementation.

That's not true, even now.
Most of the packages including ncurses/buildlink2.mk on NetBSD-current
get NetBSD curses right now (NetBSD curses are still missing some
features, but the aim is that all will use NetBSD curses at one point).
That's because both ncurses and NetBSD curses implement the X/Open
Curses specification.

Sorry, I don't get your point.
What is so special about ncurses?
 Thomas