如何在AWS Linux上完全重新安装python(没有yum)

一系列不幸的事件(在开发中，谢天谢地)基本上破坏了我的python2.7环境. /usr/bin中的可执行文件遭到破坏，某些rpm运转不佳.因此，我不再有一个可行的import yum环境.我实际上启动了另一个EC2实例，并复制了python exec，以希望lib路径相同，但可悲的是，我得到了这一点(使用-v运行):

A series of unfortunate events (in dev, thank goodness) basically has ruined my python2.7 environment. The executable in /usr/bin got clobbered and some rpms ran amok. So I no longer have a viable import yum environment. I actually spun up another EC2 instance and copied off the python exec in hopes that the lib paths would be the same but sadly I got this (running with -v):

( various imports then )
import gpg.core # precompiled from /usr/lib64/python2.7/site-packages/gpg/core.pyc
# /usr/lib64/python2.7/site-packages/gpg/gpgme.pyc matches 
/usr/lib64/python2.7/site-packages/gpg/gpgme.py
import gpg.gpgme # precompiled from /usr/lib64/python2.7/site-packages/gpg/gpgme.pyc
dlopen("/usr/lib64/python2.7/site-packages/gpg/_gpgme.so", 2);
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.7/site-packages/gpg/__init__.py", line 101, in <module>
  from . import core
File "/usr/lib64/python2.7/site-packages/gpg/core.py", line 34, in <module>
  from . import gpgme
File "/usr/lib64/python2.7/site-packages/gpg/gpgme.py", line 17, in <module>
_gpgme = swig_import_helper()
File "/usr/lib64/python2.7/site-packages/gpg/gpgme.py", line 16, in swig_import_helper
return importlib.import_module('_gpgme')
File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
ImportError: No module named _gpgme

这有点令人不安，因为当然_gpgme.so与gpgme.py在同一个目录中，而_gpgme.so上的ldd看起来还可以:

This is sort of disturbing because of course _gpgme.so is in the same dir as gpgme.py and ldd on _gpgme.so looks OK:

-bash-4.2$ ldd /usr/lib64/python2.7/site-packages/gpg/_gpgme.so
linux-vdso.so.1 =>  (0x00007ffe2cf6d000)
libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0 (0x00007ff166d5d000)
libgpgme.so.11 => /usr/lib64/libgpgme.so.11 (0x00007ff166b27000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff16690b000)
libc.so.6 => /lib64/libc.so.6 (0x00007ff166547000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007ff166343000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007ff166140000)
libm.so.6 => /lib64/libm.so.6 (0x00007ff165e3e000)
libassuan.so.0 => /usr/lib64/libassuan.so.0 (0x00007ff165c2e000)
libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007ff165a2a000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff1673e7000)

所以问题是:如何强制从AWS Linux映像(Linux version 4.9.75-25.55.amzn1.x86_64 (mockbuild@gobi-build-64013) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #1 SMP Fri Jan 5 23:50:27 UTC 2018)中删除python并重新安装没有yum的优点，然后安装必要的yum位，使得/usr/bin/yum(几乎只有import yum)有效吗?

So the question is: how does one force remove python from an AWS Linux image (Linux version 4.9.75-25.55.amzn1.x86_64 (mockbuild@gobi-build-64013) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #1 SMP Fri Jan 5 23:50:27 UTC 2018) and reinstall it WITHOUT the benefit of yum, and then install the necessary yum bits such that /usr/bin/yum (which pretty much just import yum) works?

我知道这个问题是部分重复，但我已经搜索了stackoverflow，一切似乎都导致使用yum安装python(我不能)或使用pip安装模块(这将继续使用yum安装pip！)或大致说出rpm --erase vagueness，然后是rpm -i vagueness.

I know this question is a partial dupe but I have searched stackoverflow and everything seems to lead back to installing python with yum (which I can't) or installing modules with pip (which keeps going to installing pip with yum!) or very broadly saying rpm --erase vagueness followed by rpm -i vagueness.

我确实从源代码中手动重建了一个python exec并且可以运行，但是当然它没有yum附带，而且我似乎在pip search中找不到任何东西(我再次运行pip)会产生yum我寻求的模块.您会认为pip install yum就在那里，但没有.也许我错过了什么...?

I did manually rebuild a python exec from source and that runs, but of course it does not come with yum and I cannot seem to find anything in pip search (I got pip running again) that would produce the yum module I seek. You'd think pip install yum would be right there but no. Maybe I missed something...?

我必须相信，也许有一种缓慢而稳定的方式来做到这一点.剔除/usr/bin/python2.7执行程序不应该造成我似乎遇到鸡与蛋问题的情况...

I have to believe that there is perhaps a slow but stable way to do this. Knocking out the /usr/bin/python2.7 exec shouldn't create a situation where I seem to have a chicken-and-egg problem...