How Kali deals with the upcoming Python 2 End-of-Life

五年前，Python 开发者宣布他们将在2020 年停止支持Python 2。很长一段时间没有人关心，Python 3 的采用也很缓慢。但最近情况发生了很大变化，因为截止日期即将到来（1 月1 日）。

Debian 正在删除 Python 2 支持

Debian 计划在下一个稳定版本中完全摆脱Python 2，因此他们正在逐步摆脱Python 2 代码。他们在叶包（即没有反向依赖的包）上提交了发布关键错误，要求将它们移植到Python 3。如果Python 3 移植没有足够快地进行，这些包将从Debian 测试（这是Kali 的基础）中删除。

对 Kali 的影响

应用程序消失

由于Kali 是一个滚动发行版，因此它不断接收来自Debian 测试的更新。这包括软件包因为已从Debian 中删除而“消失”的情况。然而，只要有人将它们移植到Python 3，它们就可以稍后再回来。

我们已经在zenmap 的情况下经历过这种情况，它不再由nmap 开发人员维护。因此，它不再由Debian 的nmap 源码包构建，因此不再出现在Kali 中。

损坏的应用程序

我们在Kali 中有许多Python 2 应用程序，它们使用Debian 中打包的模块。当Debian 删除此类模块的Python 2 版本时，kali-dev 中的应用程序就会被破坏。 kali-rolling 不会因为其管理方式而受到影响，但kali-dev 和kali-rolling 之间日益增长的分歧使我们的工作变得更加困难:我们没有获得此类软件包的更新，并且还有其他（最近/）应用程序可能需要这些软件包的新版本！

Kali 也必须删除 Python 2 代码

由于生态系统的这一变化，Kali 别无选择，只能效仿Debian 并删除Python 2 代码。这项巨大的努力是针对以某种方式依赖于Python 2 的所有软件包的许多GitLab 问题进行跟踪的。我们已经为所有尚不支持Python 3 的软件包提交了上游错误报告。

我们如何处理每个案例取决于许多因素:

如果上游正在支持Python 3，那么我们只需等待它准备就绪即可。如果上游不活跃或对将其代码移植到Python 3 不感兴趣，那么我们几乎没有选择:要么删除软件包；要么找到一些添加Python 3 支持的分支/补丁；要么我们自己进行移植工作（除了琐碎的脚本之外，不太可能）。这还取决于软件包的类型:

对于Python 库，这是一个两步过程: 首先我们添加Python 3 支持；一旦所有反向依赖项已更新为使用Python 3，Python 2 支持将在稍后删除。对于Python 应用程序，单个更新可能就足够了，但该更新可能取决于首先将依赖项移植到Python 3。社区是时候添加所需的Python 3 支持了。我们甚至可能修补它们，以便它们显示警告，邀请用户做出贡献，或者至少了解该应用程序可能会在不久的将来被删除。

对于不再增加太多价值的软件包，或者在Kali 中具有可行替代方案的软件包，我们可能会随时删除它们。

您如何做出贡献

如果您最喜欢的应用程序之一出现在受影响的Kali 软件包或Debian pkg-security 团队的软件包中，那么您应该检查其情况，并可能通过提交添加Python 3 支持的拉取请求来帮助上游开发人员。即使上游不是很活跃，我们也能够合并您在Kali 中的更改，并将包保留更长时间，直到上游再次活跃。

如果您不具备所需的编码技能，您仍然可以尝试找到其他人编写的Python 3 fork/patch，并在相应的GitLab 问题或Debian bug 报告中向我们指出。或者，告诉开发人员您有多喜欢他们的应用程序，并且您希望继续使用它，因此他们应该移植到Python 3。