[gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __

[Brian Harring]

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