mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-25 23:11:02 +08:00
translated
This commit is contained in:
geekpi
parent
5e7390e4cf
commit
8a9e452357
@ -1,49 +0,0 @@
|
||||
translating---geekpi
|
||||
|
||||
# [The End of the Line for EPEL-5][1]
|
||||
|
||||
|
||||
|
||||
|
||||
For the last 10 years, the Fedora Project has been building packages for the same release of another operating system. **However on March 31st, 2017, that will come to an end** when Red Hat Enterprise Linux (RHEL) version 5 moves out of production.
|
||||
|
||||
### A Short History of EPEL
|
||||
|
||||
RHEL is a downstream rebuild of a subset of Fedora releases that Red Hat feels it can adequetely support over a multi-year lifetime. While these packages make for a full operating system, there have always been a need by system administrators for ‘more’ packages. Before RHEL-5, many of these packages would be built and supplied by various rebuilders. With Fedora Extras growing to include many of the packages, and several of the rebuilders having joined Fedora, there was an idea of combining forces and creating a dedicated sub-project who would rebuild Fedora packages with specific RHEL releases and then distribute them from Fedora’s centralized servers.
|
||||
|
||||
After much debate and a failure to come up with a catchy name, the Extra Packages for Enterprise Linux (or EPEL) sub-project of Fedora was created. While at first rebuilding packages for RHEL-4, the main goal was to have as many packages available for RHEL-5 when it arrived. It took a lot of hard work getting the plague builders in place, but most of the work was in crafting the rules and guidelines that EPEL would use for the next 10 years. [As anyone can see from the old mail archives][2], the debates were fierce from both various Fedora contributors feeling this took away focus from moving Fedora releases forward to outside contributors worried about conflicts with existing installed packages.
|
||||
|
||||
In the end, EPEL-5 went live sometime in April of 2007 and over the next 10 years grew to a repository of over 5000 source packages and 200,000 unique ip addresses checking in per day at its peak of 240,000 in early 2013\. While every package built for EPEL is done with the RHEL packages, all of these packages have been useful for the various community rebuilds (CentOS, Scientific Linux, Amazon Linux) of RHEL. This meant that growth in those eco-systems brought more users into using EPEL and helping on packaging as later RHEL releases came out. However as these newer releases and rebuilds grew in usage, the number of EPEL-5 users has gradually fallen to around 160,000 unique ip addresses per day. Also over that time, the number of packages supported by developers has fallen and the repository has shrunk in size to 2000 source packages.<>
|
||||
|
||||
Part of the shrinkage was due to the original rules put in place back in 2007\. At that time, Red Hat Enterprise Linux releases were only thought to have an active life time of 6 years before being end of lifed. It was thought that for such a ‘limited’ lifetime, packages could be ‘frozen’ in EPEL like they were in the RHEL release. This meant that whenever possible fixes should be backported and major changes would not be allowed. Time and packaging stands still for no human, and packages would be continually pruned from EPEL-5 as packagers no longer wanted to try and backport fixes. While various rules were loosened to allow for larger changes in packages, the packaging rules that Fedora used have continually moved and improved from 2007\. This has made trying to rebuild a package from newer releases harder and harder with the older operating systems.
|
||||
|
||||
### What Happens on March 31st 2017
|
||||
|
||||
As stated before, on March 31st Red Hat will end of life and no longer put updates out for RHEL-5 for regular customers. This means that
|
||||
Fedora and the various rebuild distributors will start various archive processes. For the EPEL project this means that we will follow the steps that happen every year with Fedora releases.
|
||||
|
||||
1. On **March 27th**, no new builds will be allowed to be pushed for EPEL-5 so that the repository is essentially frozen. This will allow mirrors to have a clear tree of all files.
|
||||
2. All packages in EPEL-5 will be hardlinked on the master mirror from `/pub/epel/5/` and `/pub/epel/testing/5/` to `/pub/archives/epel/`. **This will start happening on the 27th** so all mirrors of archives can populate their disks.
|
||||
3. Because March 31st happens on a Friday, and system administrators do not like Friday surprises, there will be no change then. On **April 3rd**, mirrormanager will be updated to point to the archives.
|
||||
4. On **April 6th**, the /pub/epel/5/ trees will be removed and mirrors will update accordingly.
|
||||
|
||||
For a system administrator who has cron jobs which do yum updates, there should be minimal hassle. The systems will continue to update and even install any packages which were in the archives at that time. There will be breakage for system administrators who have scripts which directly download files from mirrors. Those scripts will need to change to the new canonical location of /pub/archive/epel/5/.
|
||||
|
||||
While irksome, this is a blessing in disguise for many system administrators who will still be using an older Linux. Because packages have been regularly removed from EPEL-5, the various support mailing lists and irc channels have regular requests from system administrators wondering where some package they needed has gone. After the archive is done, this won’t be a problem because no more packages will be removed :).
|
||||
|
||||
For system administrators who have been hit by this problem, the older EPEL packages are still available though in a much slower method. All EPEL packages are built in the Fedora Koji system, and so older builds of packages can be found using [Koji search.][3]
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://fedoramagazine.org/the-end-of-the-line-for-epel-5/
|
||||
|
||||
作者：[smooge][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://smooge.id.fedoraproject.org/
|
||||
[1]:https://fedoramagazine.org/the-end-of-the-line-for-epel-5/
|
||||
[2]:https://www.redhat.com/archives/epel-devel-list/2007-March/thread.html
|
||||
[3]:https://koji.fedoraproject.org/koji/search
|
||||
46
translated/tech/20170317 The End of the Line for EPEL-5.md
Normal file
46
translated/tech/20170317 The End of the Line for EPEL-5.md
Normal file
@ -0,0 +1,46 @@
|
||||
# [EPEL-5 的终点][1]
|
||||
|
||||
|
||||
|
||||
|
||||
在过去十年中，Fedora 项目一直在为同一版本的其他操作系统构建软件包。**然而，在 2017 年 3 月 31 日，它将会随着 Red Hat Enterprise Linux（RHEL）5 一起停止支持**。
|
||||
|
||||
### EPEL 的简短历史
|
||||
|
||||
RHEL 是 Fedora 发布的一个子集的下游重建，Red Hat 认为它可以获得多年的支持。虽然这些软件包可用于完整的操作系统，但系统管理员一直都需要“更多”软件包。在 RHEL-5 之前，许多软件包会由不同的人打包并提供。随着 Fedora Extras 逐渐包含了许多软件包，并有几位打包者加入了 Fedora，随之出现了一个想法，结合力量并创建一个专门的子项目，重建特定 RHEL 版本的 Fedora 软件包，然后从 Fedora 的中心化服务器上分发。
|
||||
|
||||
经过多次讨论，然而还是未能提出一个引人注目的名称，但是 Fedora 的 Enterprise Linux（或 EPEL）子项目的额外包已经创建了。在首次为 RHEL-4 重建软件包时，主要目标是在 RHEL-5 发布时提供尽可能多的用于 RHEL-5 的软件包。打包者已经采取了很多艰苦的工作，但大部分工作是在制定 EPEL 在未来十年的规则以及指导。[从所有人能够看到的邮件归档中][2]我们可以看到 Fedora 贡献者的激烈讨论，它们担心将 Fedora 的发布重心转移到外部贡献者会与已经存在的软件包产生冲突。
|
||||
|
||||
最后，EPEL-5 在 2007 年 4 月的某个时候上线，在接下来的十年中，它已经成长为一个仓库，其中包含 5000 多个源码包以及每天会有 20 万个左右独立 IP 地址检查，并在 2013 年初达到 24 万的高峰。虽然为 EPEL 构建的每个包都是使用 RHEL 软件包完成的，但所有这些软件包对于 RHEL 的各种社区重建版本（CentOS、Scientific Linux、Amazon Linux）都是有用的。这意味着随着 RHEL 版本的推出，这些生态系统的增长带来了更多的用户使用 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 发行版每年发布的步骤。
|
||||
|
||||
1. 在 ** 3 月 27 日**，任何新版本将不会被允许推送到 EPEL-5，以便仓库本质上被冻结。这允许镜像拥有一个清晰的文件树。
|
||||
2. EPEL-5 中的所有包将从主镜像 `/pub/epel/5/` 以及 `/pub/epel/testing/5/` 移动到 `/pub/archives/epel/`。 **这将会在 27 号开始*，因此所有的归档镜像可以用它写入磁盘。
|
||||
3. 因为 3 月 31 日是星期五，系统管理员并不喜欢周五惊喜，所以它不会有变化。**4 月 3 日**，镜像管理器将更新指向归档。
|
||||
4. **4 月 6 日**，/pub/epel/5/ 树将被删除，镜像也将相应更新。
|
||||
|
||||
对于使用 cron 执行 yum 更新的系统管理员而言，这应该只是一个小麻烦。系统能继续更新甚至安装归档中的任何软件包。那些直接使用脚本从镜像下载的系统管理员会有点麻烦，需要将脚本更改到 /pub/archive/epel/5/ 这个新的位置。
|
||||
|
||||
虽然令人讨厌，但是对于仍使用旧版 Linux 的许多系统管理员有一个虚假的祝福。由于软件包定期从 EPEL-5 中删除，各种支持邮件列表以及irc频道都有系统管理员定期想要知道他们需要的哪些软件包已经消失。归档完成后，这将不会是一个问题，因为不会更多的包会被删除:)。
|
||||
|
||||
对于受此问题影响的系统管理员，较旧的 EPEL 软件包仍然可用，但速度较慢。所有 EPEL 软件包都是在 Fedora Koji 系统中构建的，所以你可以使用[ Koji 搜索][3]到较旧版本的软件包。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://fedoramagazine.org/the-end-of-the-line-for-epel-5/
|
||||
|
||||
作者：[smooge][a]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://smooge.id.fedoraproject.org/
|
||||
[1]:https://fedoramagazine.org/the-end-of-the-line-for-epel-5/
|
||||
[2]:https://www.redhat.com/archives/epel-devel-list/2007-March/thread.html
|
||||
[3]:https://koji.fedoraproject.org/koji/search
|
||||
Loading…
Reference in New Issue
Block a user