NetBSD Problem Report #51728

From www@NetBSD.org  Mon Dec 19 05:03:49 2016
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 831677A2EE
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 19 Dec 2016 05:03:49 +0000 (UTC)
Message-Id: <20161219050348.43E067A329@mollari.NetBSD.org>
Date: Mon, 19 Dec 2016 05:03:48 +0000 (UTC)
From: davshao@gmail.com
Reply-To: davshao@gmail.com
To: gnats-bugs@NetBSD.org
Subject: devel/ncurses renaming of lib{form,menu,panel} should be reverted before next release
X-Send-Pr-Version: www-1.0

>Number:         51728
>Category:       pkg
>Synopsis:       devel/ncurses renaming of lib{form,menu,panel} should be reverted before next release
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    joerg
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Dec 19 05:05:01 +0000 2016
>Last-Modified:  Sun Dec 25 19:45:00 +0000 2016
>Originator:     David Shao
>Release:        current pkgsrc
>Organization:
>Environment:
DragonFly  4.7-DEVELOPMENT DragonFly v4.7.0.1029.g95ec3-DEVELOPMENT #0: Sun Dec 18 19:27:32 PST 2016     xxxxxx@:/usr/obj/usr/src/sys/X86_64_GENERIC  x86_64

>Description:
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.  Running (b)make on devel/cmake produces an error message:

-- Looking for cbreak in /usr/pkg/lib/libncurses.so - found
CMake Error at CMakeLists.txt:546 (message):
  CMAKE_USE_SYSTEM_FORM in ON but CURSES_FORM_LIBRARY is not set!

Of course building cmake cannot find CURSES_FORM_LIBRARY on this DragonFly system, because the renaming of libform in devel/ncurses broke it.  The only reason cmake still builds on some systems, perhaps almost all, is because they have a base libform for cmake to find.  Unfortunately I suspect this base library is not what is supposed to be found if one is trying to use pkgsrc ncurses as the curses replacement everywhere.

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.

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.

Given the emphasis that has been made on other pkgsrc patches being acceptable only if they can be submitted upstream, I do not see the consistency of altering devel/ncurses with patches that have no hope of inclusion upstream.







>How-To-Repeat:

>Fix:

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: pkg-manager->joerg
Responsible-Changed-By: wiz@NetBSD.org
Responsible-Changed-When: Mon, 19 Dec 2016 08:16:44 +0000
Responsible-Changed-Why:
Over to committer


From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
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 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

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@netbsd.org
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:41:49 +0000

 On Sun, Dec 25, 2016 at 07:25:00PM +0000, David Holland wrote:
  >   > 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...

 to expand on this (since on reflection I'm not sure how much you may
 know about this stuff so far)

  - work/.buildlink/lib should contain links pointing to the correct
 curses, form, panel, etc. libraries.

  - the wrappers rewrite all compiler invocations to add
 -L${WKRDIR}/.buildlink/lib.

  - either the wrappers should translate -lform to the renamed name, or
 there should be a libform.so in .buildlink/lib that's a link to the
 renamed lib. (If neither of these is the case, the renaming is broken
 and needs to be fixed. Check work/.work.log to see what the wrappers
 do.)

  - the wrappers also prune package-supplied -L options like
 -L/wrong/base/dir or -L/usr/local/lib or whatever. Also /usr/pkg/lib.

  - therefore, any package that just does -lform -lcurses will get the
 right libraries and (for the most part) will not be able to use the
 wrong libraries.

 Packages that use curses but don't include mk/curses.bl3.mk will not
 get the right sausage out. This will not keep them from building on
 systems with curses libraries on the default linker path (typically
 only /usr/lib) because the wrappers can't effectively intercept that.
 Most of these should have been found and fixed already by now,
 though.

 Packages that are too smart for their own good and do too-clever
 configure tests instead of just running the compiler like autoconf
 will sometimes find things they aren't supposed to see, draw wrong
 conclusions, and fail. This is probably what's happening with cmake.

 To fix this problem properly we need to figure out why it probed
 itself an inconsistent set of assumptions than then failed. Which
 means looking at the logic that probes for CURSES_FORM_LIBRARY and
 figuring out what it did that circumvented the wrappers.

 I am assuming CMAKE_USE_SYSTEM_FORM means "don't use some random copy
 of libform that came in the cmake distfile" and should therefore
 always be set to "ON".

 -- 
 David A. Holland
 dholland@netbsd.org

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.