On 13 September 2012 04:36, Brian Harring <[email protected]> wrote: > 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 >
I support this. It seems very sane. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
