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

[Glen Barber]

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 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.
> 

Yes, this is why I have 'KERNEL="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.
> 

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.
> 
>  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.
> 

Yes, please.

Glen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-user/attachments/20131202/3956094e/attachment.sig>