在过去的 10 年中， Fedora Project 一直在为另一个操作系统的同一版本构建软件包。 然而，在 2017 年 3 月 31 日，这将结束 当 Red Hat Enterprise Linux (RHEL) 版本 5 退出生产时。
EPEL 简史
RHEL 是一个子集的下游重建 Fedora Red Hat 认为它可以在多年生命周期内充分支持的版本。 尽管这些软件包构成了完整的操作系统，但系统管理员一直需要“更多”软件包。 在 RHEL-5 之前，许多这些软件包将由各种重建者构建和提供。 和 Fedora 附加内容越来越多，包括许多软件包，并且一些重建者已经加入 Fedora，有一个联合力量并创建一个专门的子项目来重建的想法 Fedora 具有特定 RHEL 版本的软件包，然后从 Fedora的集中式服务器。
经过多次辩论和未能想出一个吸引人的名字，企业 Linux 的额外软件包（或 EPEL）子项目 Fedora 被创建。 最初为 RHEL-4 重建软件包时，主要目标是在 RHEL-5 到达时提供尽可能多的可用软件包。 让瘟疫制造者就位需要付出很多努力，但大部分工作是制定 EPEL 将在未来 10 年使用的规则和指南。 正如任何人都可以从旧邮件档案中看到的那样双方的争论都很激烈 Fedora 贡献者认为这会转移注意力 Fedora 向担心与现有已安装软件包冲突的外部贡献者发布。
最终，EPEL-5 在 2007 年 4 月的某个时间上线，在接下来的 10 年里，它发展成为一个包含超过 5000 个源包和 200,000 个唯一 IP 地址的存储库，在 2013 年初达到 240,000 个的峰值。虽然每个包为 EPEL 构建是使用 RHEL 软件包完成的，所有这些软件包对于 RHEL 的各种社区重建（CentOS、Scientific Linux、Amazon Linux）都很有用。 这意味着随着后来 RHEL 版本的发布，这些生态系统的增长使更多用户使用 EPEL 并帮助打包。 然而，随着这些更新版本和重建的使用量增加，EPEL-5 用户的数量逐渐下降到每天大约 160,000 个唯一 IP 地址。 同样在那段时间里，开发人员支持的包数量下降了，存储库的大小缩小到 2000 个源包。<>
缩减的部分原因是 2007 年制定的原始规则。当时，红帽企业 Linux 版本被认为只有 6 年的有效生命周期才会结束生命周期。 人们认为，对于这样一个“有限”的生命周期，软件包可以在 EPEL 中“冻结”，就像它们在 RHEL 版本中一样。 这意味着应尽可能向后移植修复程序，并且不允许进行重大更改。 没有人，时间和打包就停滞不前了，由于打包者不再想尝试和向后移植修复，因此将不断地从 EPEL-5 中删除包。 虽然放宽了各种规则以允许对包装进行更大的更改，但包装规则 Fedora 使用从 2007 年开始不断移动和改进。这使得尝试使用旧操作系统从新版本重建软件包变得越来越困难。
2017 年 3 月 31 日会发生什么
如前所述，Red Hat 将于 3 月 31 日结束生命周期，不再为普通客户提供 RHEL-5 更新。 这意味着
Fedora 并且各种重建分发者将启动各种归档过程。 对于 EPEL 项目，这意味着我们将遵循每年发生的步骤 Fedora 发布。
- 在 3月27日，不允许为 EPEL-5 推送新的构建，因此存储库基本上被冻结。 这将允许镜像拥有所有文件的清晰树。
- EPEL-5 中的所有包都将从 /pub/epel/5/ 硬链接到主镜像上
和
/pub/epel/testing/5/
到
/pub/档案/epel/
. 这将从27日开始 所以档案的所有镜像都可以填充它们的磁盘。
- 因为 3 月 31 日是星期五，系统管理员不喜欢星期五的惊喜，所以不会有任何变化。 在 4月3日，mirrormanager 将更新为指向档案。
- 在 4月6日， /pub/epel/5/ 树将被删除，镜像将相应更新。
对于具有执行 yum 更新的 cron 作业的系统管理员，应该很少有麻烦。 系统将继续更新甚至安装当时存档中的任何软件包。 拥有直接从镜像下载文件的脚本的系统管理员将受到破坏。 这些脚本需要更改为 /pub/archive/epel/5/ 的新规范位置。
虽然令人讨厌，但对于许多仍将使用旧版 Linux 的系统管理员来说，这是因祸得福。 由于软件包已定期从 EPEL-5 中删除，因此各种支持邮件列表和 irc 频道都会定期收到系统管理员的请求，想知道他们需要的软件包去了哪里。 存档完成后，这将不是问题，因为不会删除更多的包:)。
对于遇到此问题的系统管理员，较旧的 EPEL 软件包仍然可用，但速度要慢得多。 所有 EPEL 包都内置在 Fedora Koji 系统，因此可以使用 小智搜索。
