Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 3 Mar 2011 12:04:00 -0800
From:      Garrett Cooper <gcooper@FreeBSD.org>
To:        Matthew Jacob <mj@feral.com>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Nathan Whitehorn <nwhitehorn@freebsd.org>, John Baldwin <jhb@freebsd.org>
Subject:   Re: svn commit: r219181 - head/release
Message-ID:  <AANLkTikjGjKoWZFhDjDmukjxEiPpK-RN6eBJpGRTLX6F@mail.gmail.com>
In-Reply-To: <4D6FEE09.5050502@feral.com>
References:  <201103021606.p22G6vou020460@svn.freebsd.org> <201103031209.43857.jhb@freebsd.org> <4D6FCE64.3010302@freebsd.org> <201103031432.36336.jhb@freebsd.org> <4D6FEE09.5050502@feral.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 3, 2011 at 11:37 AM, Matthew Jacob <mj@feral.com> wrote:
>
>
>> I think it is a very important feature to ensure release builds are not
>> polluted by local changes in /etc/src.conf, etc. =A0I think it would be =
good
>> to support both models perhaps, but for our official release builds I
>> think
>> we need the clean environment. =A0I certainly use 'make release' now for=
 my
>> own custom FooBSD builds to get a clean environment.
>>
> While not disagreeing with you on this, one should really always do 'env =
-i
> PATH=3D/usr/bin:/bin make release' if you want to ensure non-pollution.

It's more in-depth than that. The only way to ensure that the release
builds are non-tainted without doing a ton of hacks is to create an
untainted chroot/jail for the release build, or do the previous
incantation in release/Makefile, as a number of components can taint
the environment outside of PATH (see nanobsd's build scripts for a
start on this).

My personal preference is to have the scripts and infrastructure exist
within release to do this instead of within release/Makefile, but this
would require changes to any existing infrastructure that anyone
depending on release/Makefile is employing out in the field; on the
bright side maybe release/Makefile and nanobsd could converge because
they'd be using more of the same logic to run things and the things
that would truly differ are just the payload content.

Thanks,
-Garrett



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTikjGjKoWZFhDjDmukjxEiPpK-RN6eBJpGRTLX6F>