Hola folks.
Currently portage exposes a fair amount of it's internal
implementation via vars/funcs into the ebulid env; this frankly makes
it easier for ebuilds/eclasses to localize themselves to portage
(rather than PMS), leading to breakage.
Thus a proposal for EAPI5 has been made, banning ebuilds/eclasses from
using/accessing __, and requiring the PM to store it's internals in
that namespace.
Basically, instead of portage doing thus:
is_function dyn_pkg_preinst && dyn_pkg_preinst
It does thus:
__is_function __dyn_pkg_preinst && __dyn_pkg_preinst.
Aside from avoiding accidental conflicts/usage, the standardized
namespacing makes it a helluva lot easier to have repoman/qa tools
look for bad usage.
Currently, there is a minor amount of ebuild/eclass usage of things
named __*; ~90% of it is 'import once' eclass code like the following:
"""
if [[ ${___ECLASS_ONCE_LIBTOOL} != "recur -_+^+_- spank" ]] ; then
___ECLASS_ONCE_LIBTOOL="recur -_+^+_- spank
"""
Converting that is easy enough, and I'll be doing that work for
gentoo-x86 if folks don't have an issue.
Note there is a few vars we need to exempt; that list is currently
SANDBOX_* and FEATURES. FEATURES is fine to exempt from this rule.
For SANDBOX_*, while that's a PM internal, that's a bit of a grey
zone; regardless, we can actually address that via extending the
sandbox functions a bit:
addwrite [-r|--remove] pathway # for example, to do a removal.
For instances where the sandbox needs to be turned off for a command-
we do the same thing we did w/ nonfatal;
sandboxless <the command and args>
which is just
sandboxless() {
SANDBOX_ON=0 "$@"
}
or SYDBOX_ON=0 (or their equivalent var) for sydbox usage.
Comments?
~harring
