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

[Mike Frysinger]

On 12 Nov 2015 16:58, Zac Medico wrote:
> On 11/12/2015 04:06 PM, Mike Frysinger wrote:
> > 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.
>
> Sure, but do we really want to confuse people who might be ignorant of
> this rule? Having functions disappear from the environment without
> warning is very likely to cause confusion...

that already happens to a degree if you happen to use a name that portage
uses itself.  we can add a repoman check, and if we think it comes up enough,
have portage itself warn when it blows away things it didn't register.

> Also, there's the
> element of backward-compatibility for any __* functions in
> /var/db/pkg/*/*/environment.bz2 of users' installed systems that might
> be needed during pkg_prerm and pkg_postrm.

the ones i highlighted are not needed for those purposes.  you're right it
could be a problem, i think the likelihood is low considering how infrequently
these two are used, and how much we push people to use other phases instead.

> >> 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.
>
> Shrug, probably not (unless there's a bug in a particular
> implementation, and someone wants to go back and check which
> implementation was used for a particular installed package).

if we want to tag that kind of metadata in a build, we should just explicitly
include something like PORTAGE_VERSION.
-mike