Re: pkg/51728: devel/ncurses renaming of lib{form,menu,panel} should be reverted before next release

[David Holland <dholland-pbugs%netbsd.org@localhost>]

The following reply was made to PR pkg/51728; it has been noted by GNATS.

From: David Holland <dholland-pbugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: pkg/51728: devel/ncurses renaming of lib{form,menu,panel} should
 be reverted before next release
Date: Sun, 25 Dec 2016 19:20:44 +0000

 On Mon, Dec 19, 2016 at 05:05:01AM +0000, davshao%gmail.com@localhost wrote:
  > The recent change to devel/ncurses of renaming lib{form,menu,panel}
  > should be reverted before the next release.  It does not even
  > accomplish its stated purpose of fixing interaction with
  > devel/cmake; instead, it breaks it.
  > This can be seen using DragonFly 4.7-DEVELOPMENT which has
  > privatized base libraries such as (n)curses so that they are not
  > even visible to the user.
 
 It *should* fix it. The buildlink system is supposed to be able to
 hide that renaming. The problem most likely is that cmake is still
 finding traces of the base version -- in which case cmake should be
 patched and/or dfly base should hide the thing better.
 
 That or the buildlink support for the renaming is inadequate.
 
  > I argue the proper fix to the ncurses problem on NetBSD 7 is to simply make
  > 
  > PREFER_PKGSRC=yes
  > 
  > work everywhere, preferably as the default.  Especially in an era
  > of package builders, there should be as little dependency on base
  > libraries as possible.
 
 While PREFER_PKGSRC should work, it should not be the default,
 especially for something like curses where (a) the library has
 traditionally come with the base system, (b) many people don't want
 ncurses, and (c) the whole point of the builtin/buildlink framework is
 to make this sort of issue work for all cases.
 
  > To rename such well-known libraries is imposing on each porter an
  > obligation to search through the package to see whether
  > lib{form,menu,panel} are used, and if so, to find out how to rename
  > these libraries with patches that can NEVER be accepted upstream.
 
 Nope...
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost