From owner-svn-src-user@FreeBSD.ORG Mon Dec 2 15:54:28 2013 Return-Path: Delivered-To: svn-src-user@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8263E182; Mon, 2 Dec 2013 15:54:28 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 770BE1EDC; Mon, 2 Dec 2013 15:54:27 +0000 (UTC) Received: from alph.d.allbsd.org (p4181-ipbf1307funabasi.chiba.ocn.ne.jp [123.225.173.181]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id rB2Fs9cH094576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Dec 2013 00:54:20 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.7/8.14.5) with ESMTP id rB2Fs7xi072124; Tue, 3 Dec 2013 00:54:09 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 03 Dec 2013 00:52:47 +0900 (JST) Message-Id: <20131203.005247.163975247035953783.hrs@allbsd.org> To: gjb@FreeBSD.org Subject: Re: svn commit: r258848 - user/hrs/releng/release From: Hiroki Sato In-Reply-To: <20131202152054.GH1839@glenbarber.us> References: <20131202145103.GG1839@glenbarber.us> <20131203.001628.1233827032249325723.hrs@allbsd.org> <20131202152054.GH1839@glenbarber.us> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_Dec__3_00_52_47_2013_010)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Tue, 03 Dec 2013 00:54:20 +0900 (JST) X-Spam-Status: No, score=-99.1 required=13.0 tests=CONTENT_TYPE_PRESENT, SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org 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 15:54:28 -0000 ----Security_Multipart(Tue_Dec__3_00_52_47_2013_010)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Glen Barber 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)----