| 1 |
On 11/12/2015 04:06 PM, Mike Frysinger wrote: |
| 2 |
> On 11 Nov 2015 22:40, Zac Medico wrote: |
| 3 |
>> On 11/11/2015 10:33 PM, Zac Medico wrote: |
| 4 |
>>> On 11/11/2015 01:11 PM, Mike Frysinger wrote: |
| 5 |
>>>> On 11 Nov 2015 13:04, Zac Medico wrote: |
| 6 |
>>>>> On 11/11/2015 12:55 PM, Mike Frysinger wrote: |
| 7 |
>>>>>> On 11 Nov 2015 11:42, Zac Medico wrote: |
| 8 |
>>>>>>> On 11/10/2015 08:39 PM, Mike Frysinger wrote: |
| 9 |
>>>>>>>> +# Set up the bash version compatibility level. |
| 10 |
>>>>>>>> +__check_bash_version() { |
| 11 |
>>>>>>> |
| 12 |
>>>>>>> Please unset all new internal function inside bin/save-ebuild-env.sh. |
| 13 |
>>>>>>> Note that it already uses this line to unset functions beginning with |
| 14 |
>>>>>>> ___eapi: |
| 15 |
>>>>>>> |
| 16 |
>>>>>>> unset -f $(compgen -A function ___eapi_) |
| 17 |
>>>>>> |
| 18 |
>>>>>> why don't we create a new namespace for portage funcs ? something like __e* ? |
| 19 |
>>>>> |
| 20 |
>>>>> That works for me. According to PMS, we're free to do anything we want |
| 21 |
>>>>> as long as it begins with at least 2 underscores. |
| 22 |
>>>> |
| 23 |
>>>> interesting. why don't we just unmap all things that begin with 2 underscores |
| 24 |
>>>> then ? or maybe 3 ? |
| 25 |
>>> |
| 26 |
>>> Well, that's sort of a "greedy" approach when you consider that you |
| 27 |
>>> might wipe out a function defined in an eclass or ebuild. |
| 28 |
> |
| 29 |
> i'm fully aware we might clobber eclasses/ebuilds, but as you said, PMS already |
| 30 |
> says ebuilds shouldn't be using that space. |
| 31 |
> |
| 32 |
>>> Check this to |
| 33 |
>>> see what might be filtered: |
| 34 |
>>> |
| 35 |
>>> bzgrep ^__ /var/db/pkg/*/*/environment.bz2 |
| 36 |
> |
| 37 |
> i find nothing of value in there. |
| 38 |
> |
| 39 |
> from portage: |
| 40 |
> __bashpid () |
| 41 |
> __eapi6_src_install () |
| 42 |
> __eapi6_src_prepare () |
| 43 |
> __start_distcc () |
| 44 |
|
| 45 |
It's a bug that __bashpid and __start_distcc are not filtered. |
| 46 |
One of the uses of ___save_ebuild_env is to remove anything that might |
| 47 |
conflict with portage internals (__preprocess_ebuild_env uses it this way). |
| 48 |
|
| 49 |
> from ebuilds/eclasses that have already stopped using __: |
| 50 |
> __do_sed_fix () |
| 51 |
> ___ECLASS_RECUR_MULTILIB=yes |
| 52 |
> ___ECLASS_RECUR_TOOLCHAIN_FUNCS=yes |
| 53 |
> __versionator_shopt_toggle () |
| 54 |
> __versionator__test_version_compare () |
| 55 |
> __versionator__test_version_is_at_least () |
| 56 |
> |
| 57 |
> grepping the tree, i see like two packages and one eclass still using __. |
| 58 |
> both of which are trivial to convert. |
| 59 |
|
| 60 |
Sure, but do we really want to confuse people who might be ignorant of |
| 61 |
this rule? Having functions disappear from the environment without |
| 62 |
warning is very likely to cause confusion... |
| 63 |
|
| 64 |
>>> A nice compromise is to choose a namespace like __portage or something |
| 65 |
>>> like that. |
| 66 |
> |
| 67 |
> we should nuke ___* at least. i don't see any installed package using that. |
| 68 |
|
| 69 |
I guess that's safe enough to mostly avoid confusion. Also, there's the |
| 70 |
element of backward-compatibility for any __* functions in |
| 71 |
/var/db/pkg/*/*/environment.bz2 of users' installed systems that might |
| 72 |
be needed during pkg_prerm and pkg_postrm. |
| 73 |
|
| 74 |
>> Also note that some internals have been intentionally preserved in |
| 75 |
>> environment.bz2. For example, __eapi6_src_install exposes the default |
| 76 |
>> src_install implementation, which someone might examine for debugging |
| 77 |
>> purposes. |
| 78 |
> |
| 79 |
> is that actually useful ? i can't see how it would be. |
| 80 |
> -mike |
| 81 |
> |
| 82 |
|
| 83 |
Shrug, probably not (unless there's a bug in a particular |
| 84 |
implementation, and someone wants to go back and check which |
| 85 |
implementation was used for a particular installed package). |
| 86 |
-- |
| 87 |
Thanks, |
| 88 |
Zac |
Archives