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
signature.asc
Description: Digital signature
