Zac Medico wrote:
Jason Stubbs wrote:
On Monday 22 August 2005 12:52, Drake Wyrm wrote:
Alec Warner <[EMAIL PROTECTED]> wrote:
Was talking with Brian about the build environment and how settings
were to be passed into the build environment.
Essentially three scenarios were presented.
Snip and summary:
1) Pass everything
2) Blacklist and strip bad stuff
3) Whitelist good stuff; strip everything else
To me 1) is unacceptable and 3) is the best option. Feel free to
shoot these down as you see fit ;)
Option 4: Strip everything.
Nothing is passed from the original environment; everything passed in
the
environment is considered to be a "portage variable". This, I suppose,
is an extreme case of the whitelist.
Well, I'll go against the flow. ;)
My preference would go 4, 3, 2 then 1. While Makefiles and configure
scripts may be "broken" upstream, how long is it before the breakage
goes unnoticed? More importantly, what's the chances of a dev finding
the breakage before users? Cleansing the environment to me is akin to
using sandbox. It offers protection against misbehaving packages...
Good point. How about if we add environment sandboxing support (in
addition to filesystem sandboxing) to sandbox. With an environment
sandbox, we could detect specifically which variables a build is fragile
with regard to. The sandbox would have both filesystem access and
environment access violation summaries.
"environmental sandbox" being similar to sandbox, or the cleansing of
the environment? The latter is easy, the former...I am not sure how you
begin to detect variable use in bash :/
I am leaning more toward the 2,4,3,1 angle. I find the information that
variable X breaks builds more useful than having a clean environment ALL
the time. I am satisfied as long as a clean environment is an option
for those who wish their environment to be all nice and pretty ;)
I don't see exactly the difference between 4) and 3) however...4 seems
to be just a python enforced version of 3).
-Alec Warner (antarus)
--
[email protected] mailing list
