From owner-svn-src-user@FreeBSD.ORG Mon Dec 2 16:03:37 2013 Return-Path: Delivered-To: svn-src-user@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04D0445D; Mon, 2 Dec 2013 16:03:37 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B451A1F8C; Mon, 2 Dec 2013 16:03:36 +0000 (UTC) Received: from glenbarber.us (c-71-224-221-174.hsd1.nj.comcast.net [71.224.221.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 373D21AECA; Mon, 2 Dec 2013 16:03:35 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 373D21AECA Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Mon, 2 Dec 2013 11:03:33 -0500 From: Glen Barber To: Hiroki Sato Subject: Re: svn commit: r258848 - user/hrs/releng/release Message-ID: <20131202160333.GI1839@glenbarber.us> References: <20131202145103.GG1839@glenbarber.us> <20131203.001628.1233827032249325723.hrs@allbsd.org> <20131202152054.GH1839@glenbarber.us> <20131203.005247.163975247035953783.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6b3yLyRKT1M6kiA0" Content-Disposition: inline In-Reply-To: <20131203.005247.163975247035953783.hrs@allbsd.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: src-committers@FreeBSD.org, svn-src-user@FreeBSD.org X-BeenThere: svn-src-user@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the experimental " user" src tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 16:03:37 -0000 --6b3yLyRKT1M6kiA0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 03, 2013 at 12:52:47AM +0900, Hiroki Sato wrote: > 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 use= d. > 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. >=20 > That problem is not solved by forcing variable assignments for the > following two reasons: >=20 > - 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. >=20 Yes, this is why I have 'KERNEL=3D"GENERIC64"' for the powerpc64 case in the 10-amd64-powerpc64.conf script for the 10.0 builds. If you like, I can add architecture-specific things like this in ${TARGET_ARCH}/ subdirectories in release/. > - 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. >=20 Do you have an example? If you are referring to a previous problem with 10.x builds, the actual problem was a race in the build toolchain, and not variable pollution. I was able to confirm this was the case there. > 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. >=20 > Anyway, I do not have a strong opinion if using FOO=3DA or : ${FOO:=3DA}. > 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=3DA. >=20 Yes, please. Glen --6b3yLyRKT1M6kiA0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJSnK9VAAoJELls3eqvi17Q/pYP/0SIzRPGn75Yw0d7whfT2Ns8 r2D9mGZdcZwF8whyl1aTmydxA0Lh1G0WSKEjMcDb8ijVjORkyzuPpspA0qNhHXQO eaI290vVBjEqGucbqTLPcWkuhiJR72GlbI1tXZQ7eDBKxHLZLKS6uFgnkIEIITI7 zL5YANfYuKnGZECMAYn+8y83nnHlE4qF4rl7N/htJnpP2GpeTWLM2LFmVn7ri0zD U2T4ySZgfg8ryykNT/AYN6GQSqoG4nO1c6FUWfMk4OeQkxBArFhFWRK7QbEvsVUS 096AQLl2Vmnf9nMr/9T6RGvxq66YP4VkDun/cYUeeMLcRiTep1PvfRHuTM/zqzjA F2hJ6PSnhI5LmJIddY6IiB10vQ5E7D2s2Mu+ppkjJQ7+DElBu0Bc3YE9OfWnQcxd Dm3rmQoVTepzMa2c1LUuwmQserDySSAm4E3CjilrzzTk1SCRa/r4n0Z4EGQ4FVZB 0NHz0rDfE8/36G5/q5gIh36KPJ8lgkZ0HWKpE/sdW47aTi+zHM5Cpe/IaYRCGWjq e/YqPjXTQISYgBidJpmLWOThS2XMrTPc7Ofa/yAll/zooX6yoiWj+VaRvyOHScQr Vhc2A2fYdLSJf4TXXR7xgMqwHwzBCrBHZbIlUMqcLS0shvgM8Zuyal4rf478jfrn XGNNXQ29kBmtXz+nwAzX =U/xP -----END PGP SIGNATURE----- --6b3yLyRKT1M6kiA0--