在过去十年中，Fedora 项目一直都在为另外一个操作系统构建相同软件包。然而，到 2017 年 3 月 31 日，它将会随着 Red Hat Enterprise Linux（RHEL）5 一起停止这项工作。
EPEL 的简短历史
RHEL 是 Fedora 发布版本的一个子集的下游重建版本，Red Hat 愿为之支持好多年。虽然那些软件包构成了完整的操作系统，但系统管理员一直都需要“更多”软件包。在 RHEL-5 之前，许多那些软件包会由不同的人打包并提供。随着 Fedora Extras 逐渐包含了更多软件包，并有几位打包者加入了 Fedora，随之出现了一个想法，结合力量并创建一个专门的子项目，重建特定于 RHEL 版本的 Fedora 软件包，然后从 Fedora 的中心化服务器上分发。
经过多次讨论，然而还是未能提出一个引人注目的名称之后，Fedora 创建了子项目 Extra Packages for Enterprise Linux（简称 EPEL）。在首次为 RHEL-4 重建软件包时，其主要目标是在 RHEL-5 发布时提供尽可能多的用于 RHEL-5 的软件包。打包者做了很多艰苦的工作，但大部分工作是在制定 EPEL 在未来十年的规则以及指导。从所有人能够看到的邮件归档中我们可以看到 Fedora 贡献者的激烈讨论，它们担心将 Fedora 的发布重心转移到外部贡献者会与已经存在的软件包产生冲突。
最后，EPEL-5 在 2007 年 4 月的某个时候上线了，在接下来的十年中，它已经成长为一个拥有 5000 多个源码包的仓库，并且每天会有 20 万个左右独立 IP 地址检查软件包，并在 2013 年初达到 24 万的高峰。虽然为 EPEL 构建的每个包都是使用 RHEL 软件包完成的，但所有这些软件包可以用于 RHEL 的各种社区重建版本（CentOS、Scientific Linux、Amazon Linux）。这意味着随着这些生态系统的增长，给 EPEL 带来了更多的用户，并在随后的 RHEL 版本发布时帮助打包。然而，随着新版本以及重建版本的使用量越来越多，EPEL-5 的用户数量逐渐下降为每天大约 16 万个独立 IP 地址。此外，在此期间，开发人员支持的软件包数量已经下降，仓库大小已缩小到 2000 个源代码包。
收缩的部分原因是由于 2007 年的原始规定。当时，Red Hat Enterprise Linux 被认为只有 6 年活跃的生命周期。有人认为，在这样一个“有限”的周期中，软件包可能就像在 RHEL 中那样在 EPEL 中被“冻结”。这意味着无论何时有可能的修复需要向后移植，也不允许有主要的修改。因为没有人来打包，软件包将不断从 EPEL-5 中移除，因为打包者不再想尝试并向后移植。尽管各种规则被放宽以允许更大的更改，Fedora 使用的打包规则从 2007 年开始不断地改变和改进。这使得在较旧的操作系统上尝试重新打包一个较新的版本变得越来越难。
2017 年 3 月 31 日会发生什么
如上所述，3 月 31 日，红帽将终止 RHEL-5 的支持并不再为普通客户提供更新。这意味着 Fedora 和各种重建版本将开始各种归档流程。对于 EPEL 项目，这意味着我们将跟随 Fedora 发行版每年发布的步骤。
/pub/epel/5/ 以及 /pub/epel/testing/5/ 移动到 /pub/archives/epel/。 这将会在 27 号开始，因此所有的归档镜像站点可以用它写入磁盘。/pub/epel/5/ 树将被删除，镜像也将相应更新。对于使用 cron 执行 yum 更新的系统管理员而言，这应该只是一个小麻烦。系统能继续更新甚至安装归档中的任何软件包。那些直接使用脚本从镜像下载的系统管理员会有点麻烦，需要将脚本更改到 /pub/archive/epel/5/ 这个新的位置。
虽然令人讨厌，但是对于仍使用旧版 Linux 的许多系统管理员也许算是好事吧。由于软件包不断地从 EPEL-5 中删除，各种支持邮件列表以及 irc 频道都有系统管理员惊奇他们需要的哪些软件包消失到哪里了。归档完成后，这将不会是一个问题，因为不会更多的包会被删除了 :)。
对于受此问题影响的系统管理员，较旧的 EPEL 软件包仍然可用，但速度较慢。所有 EPEL 软件包都是在 Fedora Koji 系统中构建的，所以你可以使用 Koji 搜索到较旧版本的软件包。
via: https://fedoramagazine.org/the-end-of-the-line-for-epel-5/
作者：smooge 译者：geekpi 校对：wxy
本文由 LCTT 原创编译，Linux中国 荣誉推出
