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

From: nbgnats@anastigmatix.net
To: gnats-bugs@netbsd.org
Cc: 
Subject: spurious apostrophes in PKGNAME_REQD - prereq to pkg/30954
Date: Wed, 10 Aug 2005 00:10:26 +0000 (UTC)

 >Submitter-Id:	net
 >Originator:	Chapman Flack
 >Organization:	
 >Confidential:	no
 >Synopsis:	spurious apostrophes in PKGNAME_REQD - prereq to pkg/30954
 >Severity:	serious
 >Priority:	medium
 >Category:	pkg
 >Class:		sw-bug
 >Release:	2.0.0 (irrelevant to issue)
 >Environment:	NetBSD lundestad.anastigmatix.net 2.0 NetBSD 2.0 (lundestad) #11: Sat Mar  5 14:01:49 EST 2005  xxx@xxx:/usr/src/sys/arch/i386/compile/lundestad i386 (irrelevant to issue)
 >Description:
 The value of PKGNAME_REQD is not directly usable because it usually contains
 spurious apostrophes that have to be stripped out. However, the apostrophes were
 added (1.1300) as a workaround for a particular platform that had buggy behavior
 in 2003, and if that system is still buggy, the apostrophes will NOT be seen
 when running on that platform (because it will have consumed them as quotes,
 where on a non-buggy system they are part of the literal value). That's even
 worse: users of PKGNAME_REQD now have to treat it as a value that will USUALLY
 BUT NOT ALWAYS have spurious apostrophes, and so now any use of PKGNAME_REQD has
 to contain a conditional workaround of the problem caused by the workaround
 created for a buggy platform in 2003. Also, the change reintroduced a a risk of
 surprise from strange IFS values or globbing with unluckily-named files in the
 filesystem that had been fixed in 1.1275 (Sep 2003).
 
 Happily, there is only one package I know of at present that uses PKGNAME_REQD:
 lang/python/extension.mk had to have a workaround added (1.6) when the
 apostrophes appeared in the value. Therefore, fixing this issue would not
 require much effort in backing out workarounds: lang/python/extension.mk would
 need to have 1.6 backed out. However, this issue has greater impact than just
 lang/python, because it blocks pkg/30954, which impairs functionality of
 bin-install.
 
 RECOMMENDATION IN BRIEF:
 
   Revert the line
 
     ${MAKE} ${MAKEFLAGS} $$target ... PKGNAME_REQD=\'$$pkg\';
 
   to its form as of 1.1275:
 
     ${MAKE} ${MAKEFLAGS} $$target ... PKGNAME_REQD="$$pkg";
     
   Back out revision 1.6 of lang/python/extension.mk.
 
   Then, IF the symptom seen building mplayer on Linux in 2003 reappears--it may
   not, if an underlying bug with that platform got fixed in the meantime--I'll
   be happy to help look for the real problem, toward developing a targeted
   workaround or genuine fix. A test Makefile and some debugging suggestions
   were included in http://mail-index.netbsd.org/tech-pkg/2005/03/19/0011.html.
   The test Makefile can be used to test for problems on a suspect platform
   without waiting for a failed package build.
 
 The recommendation is very short and simple (and there's a patch at the end).
 The reason this PR is long is that it might be counterintuitive--there was a
 problem reported, a change was made that seemed to fix it, why go back? I'll try
 to show carefully why the fix was an accident and something else should be done.
 
 HISTORY AND DETAILS:
 
 [the web PR submission form lost this PR the first time; maybe it was
 too long. I'll see if it will accept this much and let me add the rest with an e-mail reply]
 >How-To-Repeat:
 With make -dv, can confirm that PKGNAME_REQD value contains apostrophes when bin-install invoked for dependencies (can be masked by pkg/30928--fix that to make sure bin-install GETS invoked for dependencies).
 
 See http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/lang/python/extension.mk#rev1.6 for example of package rework required by the insertion of spurious apostrophes.
 >Fix:
 PATCH FOR bsd.pkg.mk:
 
 --- /tmp/bsd.pkg.mk	2005-08-09 14:32:15.000000000 -0500
 +++ /tmp/bsd.pkg.mk	2005-08-09 16:53:46.000000000 -0500
 @@ -3611,8 +3611,8 @@
  .    else	# !DEPENDS
  .      for dep in ${_DEPENDS_AND_BUILD_DEPENDS:O}
  	${_PKG_SILENT}${_PKG_DEBUG}					\
 -	pkg="${dep:C/:.*//}";						\
 -	dir="${dep:C/[^:]*://:C/:.*$//}";				\
 +	pkg=${dep:C/:.*//:Q};					       \
 +	dir=${dep:C/[^:]*://:C/:.*$//:Q};			       \
  	found=`${PKG_BEST_EXISTS} "$$pkg" || ${TRUE}`;			\
  	if [ "X$$REBUILD_DOWNLEVEL_DEPENDS" != "X" ]; then		\
  		pkgname=`cd $$dir ; ${MAKE} ${MAKEFLAGS} show-var VARNAME=PKGNAME`; \
 @@ -3644,7 +3644,7 @@
  			${ECHO_MSG} "=> No directory for $$dir.  Skipping.."; \
  		else							\
  			cd $$dir ;					\
 -			${SETENV} _PKGSRC_DEPS=", ${PKGNAME}${_PKGSRC_DEPS}" ${MAKE} ${MAKEFLAGS} $$target PKGNAME_REQD=\'$$pkg\' MAKEFLAGS="" || exit 1; \
 +			${SETENV} _PKGSRC_DEPS=", ${PKGNAME}${_PKGSRC_DEPS}" ${MAKE} ${MAKEFLAGS} $$target PKGNAME_REQD="$$pkg" MAKEFLAGS="" || exit 1; \
  			${ECHO_MSG} "${_PKGSRC_IN}> Returning to build of ${PKGNAME}"; \
  		fi;							\
  	fi
 
 THEN REVERT r1.6 of lang/python/extension.mk.
 
 The original problem on some platform that the apostrophes were an attempt to fix *may* reappear; if it does, I'll be happy to help find the real cause and solution. Some debug ideas, if necessary, in http://mail-index.netbsd.org/tech-pkg/2005/03/19/0011.html