Only since the latest release of portage warns, "QA Notice: $command in global scope:", have I come to realize that I haven't been submitting proper ebuilds. Before submitting any, I had read the ebuild policy and thought my ebuilds decent enough to submit. It would have been nice to know that global scope is bad. So I think its worth mentioning in the handbook's ebuild policy section.
Suggested text, please comment: Scope ===== Whenever an ebuild is sourced, the functions and variables within it are loaded into memory by the script interpreter. However, only variables and instructions that are not part of a function are interpreted - functions such as src_compile() are only executed by Portage when the ebuild has reached the compile stage. Such functions are in "local scope", while variables and instructions are in "global scope", meaning that they are executed each time the ebuild is read by the interpreter. An external application (such as grep, sed or awk) should never be called in global scope for performance reasons, and alternatives such as using built-in bash replacement should be used instead. Additionally, any external application that may be called in global scope can not be guaranteed to exist on the system, while in local scope (for example, in the pkg_setup() function) this possibility is less likely since the needed application could be installed via ${DEPEND}, for example.
Just a couple suggestions Whenever an ebuild is sourced, the functions and variables within it are loaded into memory by the script interpreter. However, only variables and instructions that are not part of a function are interpreted - functions such as src_compile() are only executed by Portage when the ebuild has reached the compile stage. The code within these functions are considered in "local scope" while everything outside of the functions is in the "global scope" meaning they are executed every time the ebuild is sourced. An external application (such as grep, sed or awk) should never be called in global scope for performance reasons, and alternatives such as using built-in bash replacement should be used instead. Most useful alternatives can be found in the Advanced Bash Scripting Guide (http://www.tldp.org/LDP/abs/html/). Additionally, any external application that may be called in global scope can not be guaranteed to exist on the system. If the action is placed in local scope (for example, in the pkg_setup() function), we can gurantee its presence by placing it in the ebuild's ${DEPEND}.
In CVS, update should reach the web nodes within a few hours. Please reopen this bug if you have any problems. Thanks!
