svn commit: r258848 - user/hrs/releng/release

[Hiroki Sato]

Glen Barber <gjb at FreeBSD.org> wrote
  in <20131202152054.GH1839 at glenbarber.us>:

gj> On Tue, Dec 03, 2013 at 12:16:28AM +0900, Hiroki Sato wrote:
gj> >  Everything can be overridden by a configuration file regardless of
gj> >  whether envvars are honored even after this change.  What is the
gj> >  problem?  I do not see negative effect assuming a conf file is used.
gj> >
gj>
gj> This allows the host environment to accidentally pollute the build if
gj> something is not set in configuration file and unintentionally set in
gj> the builder's environment.
gj>
gj> It was why I specifically did not allow the environment to affect the
gj> build process.

 That problem is not solved by forcing variable assignments for the
 following two reasons:

 - A case that "something is not set in configuration file" can still
   cause unexpected failures because release.sh does not always set
   the reasonable default values.  A powerpc64 build fails, for
   example.

 - In the current release.sh, variables unintentionally set in the
   builder's environment still pollutes commands which run in
   release.sh when the variables are not set in the script but
   accepted by make or other utilities.  Catching all of the variables
   is quite difficult.

 So, clearing the envvars before running the script is needed even for
 the current release.sh to solve the problem.  "env -i" does it.  It
 is not unrealistic to assume that we can eliminate variables which
 are set unexpectedly.

 Anyway, I do not have a strong opinion if using FOO=A or : ${FOO:=A}.
 I agree that the latter assumes all of the envvars must be under
 control and it needs one more step than just invoking the script, and
 a leaked variable can break the build.  If you do not like it, I will
 change them with FOO=A.

-- Hiroki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-user/attachments/20131203/1c7c45bb/attachment.sig>