Re: pkg/30956

[Chapman Flack <nbgnats%anastigmatix.net@localhost>]

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

From: Chapman Flack <nbgnats%anastigmatix.net@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: pkg/30956
Date: Tue, 09 Aug 2005 19:46:53 -0500

 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:
 
 (to be added)