Re: pkg/57282: Package audio/mp3blaster compile fails if ncurses package installed

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

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

From: David Holland <dholland-pbugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: jspath55%gmail.com@localhost
Subject: Re: pkg/57282: Package audio/mp3blaster compile fails if ncurses
 package installed
Date: Fri, 12 May 2023 09:24:52 +0000

 On Thu, May 11, 2023 at 11:55:01AM +0000, Jim Spath wrote:
  >  Before checking the first 2, I definitely use symbolic links for pkg/pkgsrc:
  >  
  >  lrwxr-xr-x   1 root  wheel      9 Feb 15 19:44 pkg -> /home/pkg
  >  lrwxr-xr-x   1 root  wheel     12 Feb 15 19:43 pkgsrc -> /home/pkgsrc
  >  
  >  I will check the other suggestions. This must be an obscure issue, as
  >  I have used symlinks for pkgsrc on many previous versions without
  >  seeing those symptoms.
 
 Yeah, it is fairly obscure. The problem is that the buildlink/wrapper
 scheme rewrites references to the installed package tree (to refer to
 work/.buildlink instead) and this doesn't work reliably if there are
 multiple names for it.
 
 Which means that now and then something like this happens, but it
 depends heavily on circumstances and usually only comes up if the
 package is trying to be too smart for its own good. In this case it
 appears that mp3blaster's configure script explicitly tries to look in
 /usr/pkg, and for whatever reason it was able to see the ncurses
 library but not the headers.
 
 Ideally this would be handled better but it's not entirely trivial to
 discover all the names, especially in more complicated cases.
 (Consider for example /usr/pkg -> /usr/local/pkg and /usr/local ->
 /home/local, which is an entirely reasonable setup.) So the solution
 so far has been to say "don't do that".
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost