Date: Mon, 2 Dec 2013 11:03:33 -0500 From: Glen Barber <gjb@FreeBSD.org> To: Hiroki Sato <hrs@FreeBSD.org> Cc: src-committers@FreeBSD.org, svn-src-user@FreeBSD.org Subject: Re: svn commit: r258848 - user/hrs/releng/release Message-ID: <20131202160333.GI1839@glenbarber.us> In-Reply-To: <20131203.005247.163975247035953783.hrs@allbsd.org> References: <20131202145103.GG1839@glenbarber.us> <20131203.001628.1233827032249325723.hrs@allbsd.org> <20131202152054.GH1839@glenbarber.us> <20131203.005247.163975247035953783.hrs@allbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131202160333.GI1839>