Re: [gentoo-portage-dev] [PATCH] ebuild: set up bash compat levels

[Mike Frysinger]

On 11 Nov 2015 22:40, Zac Medico wrote:
> On 11/11/2015 10:33 PM, Zac Medico wrote:
> > On 11/11/2015 01:11 PM, Mike Frysinger wrote:
> >> On 11 Nov 2015 13:04, Zac Medico wrote:
> >>> On 11/11/2015 12:55 PM, Mike Frysinger wrote:
> >>>> On 11 Nov 2015 11:42, Zac Medico wrote:
> >>>>> On 11/10/2015 08:39 PM, Mike Frysinger wrote:
> >>>>>> +# Set up the bash version compatibility level.
> >>>>>> +__check_bash_version() {
> >>>>>
> >>>>> Please unset all new internal function inside bin/save-ebuild-env.sh.
> >>>>> Note that it already uses this line to unset functions beginning with
> >>>>> ___eapi:
> >>>>>
> >>>>>    unset -f $(compgen -A function ___eapi_)
> >>>>
> >>>> why don't we create a new namespace for portage funcs ?  something like __e* ?
> >>>
> >>> That works for me. According to PMS, we're free to do anything we want
> >>> as long as it begins with at least 2 underscores.
> >>
> >> interesting.  why don't we just unmap all things that begin with 2 underscores
> >> then ?  or maybe 3 ?
> >
> > Well, that's sort of a "greedy" approach when you consider that you
> > might wipe out a function defined in an eclass or ebuild.

i'm fully aware we might clobber eclasses/ebuilds, but as you said, PMS already
says ebuilds shouldn't be using that space.

> > Check this to
> > see what might be filtered:
> >
> >   bzgrep ^__ /var/db/pkg/*/*/environment.bz2

i find nothing of value in there.

from portage:
__bashpid ()
__eapi6_src_install ()
__eapi6_src_prepare ()
__start_distcc ()

from ebuilds/eclasses that have already stopped using __:
__do_sed_fix ()
___ECLASS_RECUR_MULTILIB=yes
___ECLASS_RECUR_TOOLCHAIN_FUNCS=yes
__versionator_shopt_toggle ()
__versionator__test_version_compare ()
__versionator__test_version_is_at_least ()

grepping the tree, i see like two packages and one eclass still using __.
both of which are trivial to convert.

> > A nice compromise is to choose a namespace like __portage or something
> > like that.

we should nuke ___* at least.  i don't see any installed package using that.

> Also note that some internals have been intentionally preserved in
> environment.bz2. For example, __eapi6_src_install exposes the default
> src_install implementation, which someone might examine for debugging
> purposes.

is that actually useful ?  i can't see how it would be.
-mike