Hi,

Before 1.1296, bsd.pkg.mk had this line in a shell command:

  ${MAKE} ${MAKEFLAGS} $$target ... PKGNAME_REQD="$$pkg";

in 1.1296, grant changed it to this:

  ${MAKE} ${MAKEFLAGS} $$target ... PKGNAME_REQD=\""$$pkg"\";

in 1.1298, agc reverted the change.

in 1.1300, grant tried it this way (as it is to this day):

  ${MAKE} ${MAKEFLAGS} $$target ... PKGNAME_REQD=\'$$pkg\';

The concern, of course, is that the value usually looks something like
foo>=1.2.2, and if it appears in any shell command improperly quoted,
then somebody gets the wrong package name *and* a file =1.2.2 gets created
somewhere.

The trouble is, the very first version above, before any changes, was the
properly-quoted one.  The versions with \" and \' do not quote the package
name from the shell - they insert literal " or ' characters into the
package name!  If that corrected any problem, it's only by accident;
meanwhile it broke lang/python/extension.mk (currently 100% of the uses
of PKGNAME_REQD :), requiring a workaround (1.6) to ignore the spurious '
characters in the package name.  I am ready to use PKGNAME_REQD myself
and I would rather find the solution to the original problem so we don't
proliferate those workarounds.

The first commit message spoke of a problem instance on linux building
audio/nas from graphics/mplayer.  Was the problem replicable on other
platforms than linux?  What make was being used?

The shell command ${MAKE} ... PKGNAME_REQD="$pkg" will never see redirection
symbols in the value of pkg.  The other time you might see the assignment
PKGNAME_REQD=foo>=1.2.2 is ... in any later recursive invocation of make.
Because PKGNAME_REQD was assigned on the command line, it went into
.MAKEOVERRIDES and wound up in MAKEFLAGS, so it will be on every later
${MAKE} ${MAKEFLAGS} command line.  If the make program quotes characters
in MAKEFLAGS properly--and /usr/bin/make on NetBSD 2.0 does, I've just been
testing it--there's no problem.  But it wouldn't surprise me if some other
make implementation is getting that wrong.  It would be good to find the
culprit and report the bug.

Can somebody with access to a system that had problems run the attached
test Makefile with the available make?  It should do the same sequence of
two recursive invocations forever (well, until fork fails).  If the value
of PKGNAME_REQD changes from one to the next, there's a make or shell bug.

Another thing to do would be retry the failing package build on a problem
system, find where an =n.n.n file got created, and then replace that file
with a fifo and run the build again.  Things will nicely stop when a shell
redirects to that fifo, and it will be easy to see which process is the
culprit and, more important, follow PPID to find the culprit's *parent*.

Here's a test Makefile.  It does *not* have problems with NetBSD 2.0 native
make and sh.

-Chap

# run me with: make PKGNAME_REQD="foo>=1.2.2"
# or: make -dv PKGNAME_REQD="foo>=1.2.2"

PKGNAME=foo-1.2.3

foo :
	unset MAKEFLAGS ; \
	echo ${PKGNAME_REQD:U${PKGNAME}:Q} ; \
	${MAKE} ${MAKEFLAGS} bar

bar :
	unset MAKEFLAGS ; \
	pkg=${PKGNAME_REQD:U${PKGNAME}:Q} ; \
	echo "$$pkg" ; \
	${MAKE} ${MAKEFLAGS:C@[^-]*((-d v)?).*@\1@W} PKGNAME_REQD="$$pkg" foo