Alec Warner wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Was talking with Brian about the build environment and how settings were
to be passed into the build environment.
Essentially three scenarios were presented.
1) The full environment is passed to the build environment. This was
generally agreed upon to be bad since there are environmental things
that can cause build problems.
2) The full environment is parsed via a blacklist to strip out
environment settings that are known to be bad for building packages.
This leads to a clean* build environment. However, maintaining the
blacklist can be a challenge if it grows in size.
(*) clean, meaining all the bad things we know about are not in the
build environment. This does not account for the bad things we do NOT
know about.
3) The full environment is parsed via a whitelist to get a list of
environment settings that are known to be good for building packages.
This leads to a clean build environment, as only whitelisted environment
settings are passed in. However, the whitelist will probably be worse
to maintain than a blacklist.
Both 2) and 3) above have issues where some build variables are bad for
ebuild X but not ebuild Y. I am unsure how exactly to cover any kind of
situation like that ( and I don't have an example from the tree, save
perhaps LANG=weird-language ).
To me 1) is unacceptable and 3) is the best option. Feel free to shoot
these down as you see fit ;)
IMO the whitelist is a bad thing. I would suggest a blacklist and an override list. The blacklist
simply removes known "problem causing" variables. The override list allows known
"problem causing" variables to be overridden.
Zac
--
[EMAIL PROTECTED] mailing list
