译者：geekpi
在过去的十年中，Fedora 项目一直在为另一个操作系统构建相同的包。但是，从 2017 年 3 月 31 日起，它将停止与 Red Hat Enterprise Linux (RHEL) 5 一起使用。
EPEL的简史
RHEL 是 Red Hat 多年来支持的 Fedora 版本子集的下游重建。虽然这些软件包构成了一个完整的操作系统，但系统管理员始终需要“更多”软件包。在 RHEL-5 之前，许多这些软件包将由不同的人打包和提供。随着 Fedora Extras 逐渐包含更多的包，并且有几个打包者加入了 Fedora，一个想法出现了，联合力量，创建一个专门的子项目来重建特定于 RHEL 版本的 Fedora 包，然后从 Fedora 的中心化服务器分发。
经过多次讨论，但未能提出一个引人注目的名称，Fedora 创建了一个子项目 Extra Packages for Enterprise Linux（简称 EPEL）。首次为 RHEL-4 重建软件包时，主要目标是在 RHEL-5 发布时为 RHEL-5 提供尽可能多的软件包。打包人员做了很多艰苦的工作，但大部分工作是为未来十年的 EPEL 制定规则和指导方针。从所有 [1] 可用的电子邮件档案中，我们可以看到 Fedora 贡献者之间的激烈讨论，他们担心将 Fedora 的分发重点转移到外部贡献者会与现有的软件包发生冲突。
最后，EPEL-5 在 2007 年 4 月的某个时间上线，在接下来的十年里，它已经发展成为一个拥有超过 5,000 个源包和每天大约 200,000 个唯一 IP 地址的存储库。检查包并在 2013 年初达到 240k 的峰值。虽然每个包都构建因为 EPEL 是使用 RHEL 包完成的，所有这些包都可用于 RHEL 的各种社区重建（CentOS、Scientific Linux、Amazon Linux）。这意味着随着这些生态系统的发展，它将为 EPEL 带来更多用户，并在随后的 RHEL 版本发布时帮助打包。然而，随着新版本和重建版本的使用越来越多，EPEL-5 的用户数量逐渐下降到每天大约 160,000 个唯一 IP 地址。此外，在此期间开发人员支持的软件包数量有所下降，
部分收缩是由于最初的 2007 年规定。当时，红帽企业 Linux 被认为只有六年的活跃生命周期。有人认为，在这样一个“有限”周期内邮件归档后存在了什么地方，EPEL 中的软件包可能会像在 RHEL 中一样被“冻结”。这意味着只要可能的修复需要向后移植，就不允许进行重大修订。软件包将不断从 EPEL-5 中删除，因为没有人会打包它们，因为打包者不再想尝试和向后移植。Fedora 使用的打包规则自 2007 年以来不断变化和改进，尽管各种规则已经放宽以允许更大的变化。这使得尝试在旧操作系统上重新打包新版本变得越来越困难。
2017 年 3 月 31 日会发生什么
如上所述，3 月 31 日，Red Hat 将结束对 RHEL-5 的支持，并且不再向普通客户提供更新。这意味着 Fedora 和各种重建将启动各种归档过程。对于 EPEL 项目，这意味着我们将遵循 Fedora 发行版每年发布的步骤。
3 月 27 日，不允许将任何新版本推送到 EPEL-5，因此存储库基本上被冻结。这允许图像具有干净的文件树。
EPEL-5 中的所有包将从主镜像 /pub/epel/5/ 和 /pub/epel/testing/5/ 移动到 /pub/archives/epel/。这将从 27 日开始，因此所有存档镜像站点都可以使用它来写入磁盘。
由于 3 月 31 日是星期五，系统管理员不喜欢星期五的惊喜，所以它不会改变。4 月 3 日，图像管理器将更新指向存档。
4 月 6 日邮件归档后存在了什么地方，/pub/epel/5/ 树将被删除，镜像将相应更新。
对于使用 cron 执行 yum 更新的系统管理员来说，这应该只是一个小麻烦。系统可以继续更新甚至安装存档中的任何软件包。那些使用脚本直接从镜像下载的系统管理员会有点麻烦，需要将脚本更改为新位置/pub/archive/epel/5/。
这很烦人，但对于许多仍在使用旧版本 Linux 的系统管理员来说，这可能是件好事。随着软件包不断从 EPEL-5 中删除，各种支持邮件列表和 irc 频道让系统管理员想知道他们需要哪些软件包已经消失以及消失在哪里。归档完成后，这将不是问题，因为不会删除更多的包:)。
对于受此问题影响的系统管理员，较旧的 EPEL 软件包仍然可用，但速度较慢。所有的 EPEL 软件包都是在 Fedora Koji 系统上构建的，因此您可以使用 Koji 搜索[2] 旧版本的软件包。
通过：
作者：smooge[3] 译者：geekpi 校对：wxy
本文由LCTT原创编译，Linux中国首发
