Date: Tue, 03 Dec 2013 00:52:47 +0900 (JST) From: Hiroki Sato <hrs@FreeBSD.org> To: gjb@FreeBSD.org Cc: src-committers@FreeBSD.org, svn-src-user@FreeBSD.org Subject: Re: svn commit: r258848 - user/hrs/releng/release Message-ID: <20131203.005247.163975247035953783.hrs@allbsd.org> In-Reply-To: <20131202152054.GH1839@glenbarber.us> References: <20131202145103.GG1839@glenbarber.us> <20131203.001628.1233827032249325723.hrs@allbsd.org> <20131202152054.GH1839@glenbarber.us>
next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart(Tue_Dec__3_00_52_47_2013_010)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Glen Barber <gjb@FreeBSD.org> wrote
in <20131202152054.GH1839@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
----Security_Multipart(Tue_Dec__3_00_52_47_2013_010)--
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (FreeBSD)
iEYEABECAAYFAlKcrM8ACgkQTyzT2CeTzy1afQCgvAxbI9bNK0IJ2R7J1cOO9YEW
NVkAoJKyXQ6GbZlt03241KAgO6FPHfb1
=Okf1
-----END PGP SIGNATURE-----
----Security_Multipart(Tue_Dec__3_00_52_47_2013_010)----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131203.005247.163975247035953783.hrs>