ports/184339: lang/python27 does not allow unsetting NLS (or other options)

John Hein jhein at symmetricom.com
Thu Dec 5 20:10:01 UTC 2013


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

From: John Hein <jhein at symmetricom.com>
To: bug-followup at FreeBSD.org
Cc: <gerald at pfeifer.com>, <koobs at FreeBSD.org>, <freebsd-python at FreeBSD.org>
Subject: Re: ports/184339: lang/python27 does not allow unsetting NLS (or other options)
Date: Thu, 5 Dec 2013 13:04:30 -0700

 It's something of a complicated interaction.  But the reason you see a
 difference in lang/python27 vs. say, lang/gcc boils down to having
 OPTIONS_FILE_SET+=NLS in the saved options file _and_ NLS in
 OPTIONS_DEFINE.  If so, bsd.options.mk overrides the WITHOUT_NLS
 setting.
 
 This could be considered a bug, but maybe it's just somewhat
 unexpected.  koobs' comment is correct but slightly incomplete -
 WITHOUT_NLS loses to the options file even if set in the port's
 Makefile or make.conf, not just the command line.  And it's not clear
 that the deprecation (which is not clearly documented that I could
 find - but I could have missed where it is spelled out) is meant to
 apply to settings in Makefile / make.conf.
 
 I could see this being an issue for a slave port that explicitly sets
 WITHOUT_XXX to override a master port option setting.  Probably the
 right thing in that case is to use a mechanism to exclude XXX from the
 master's OPTIONS list when building the slave port.
 
 Anyway, it's not obvious to me that the options file should override
 WITH_*/WITHOUT_* settings or vice versa.  It's not apparent that a
 setting in the options file should override make.conf.  Maybe the
 option file setting should have a choice to "obey any global setting
 first" for a particular option in addition to just allowing it to be
 set or unset.
 
 Having WITHOUT_* work in some cases but not others consistently seems
 like a potential source of confusion if the rules are not spelled out
 clearly.
 
 As far as python27, I'm not sure why NLS is in the OPTIONS_DEFINE list
 instead of just relying on the fact that NLS is a global option.  As
 far as I understand it, NLS could be removed from OPTIONS_DEFINE for
 python27 (& other pythonXY ports).  It has a slightly different
 NLS_DESC than the default option, but I'm not sure that nuanced
 distinction is important in this case.  Unless there's a good reason
 I'm missing to have NLS in OPTIONS_DEFINE, I'd vote on removing it
 from OPTIONS_DEFINE in python* (and EXAMPLES and IPV6, too, I suppose).


More information about the freebsd-python mailing list