在使用 CentOS 第三方存储库时，存在很多恐惧、不确定性和怀疑。这是一段来自CentOS 的存储库页面特别是关于 EPEL：
Enterprise Linux (EPEL) 的额外软件包 -（请参阅http://fedoraproject.org/wiki/EPEL）为 EL6 和 EL7 提供 Fedora 软件包的重建。套餐不应该替换基础，尽管过去在点发布方面存在问题。您可以通过运行 yum --enablerepo=extras install epel-release 来安装 EPEL。 epel-release 软件包包含在默认启用的 CentOS Extras 存储库中。 #epel 中的 Freenode、邮件列表及其问题跟踪器提供支持。如果您愿意在 EPEL 更新推送到稳定版之前帮助测试它们，您可以在开发/测试服务器上启用 epel-testing 存储库。在生产系统上启用 epel 测试并不是一个好主意。
我对这句话深有同感“不应该”。这几乎就像 CentOS 文档所说的“如果您使用 EPEL，事情应该没问题 - 但谁知道，也可能会发生一些非常糟糕的事情，尤其是在点发布方面”。
这是前一节的内容CentOS 的存储库页面总结了问题并就如何解决该问题提出了三项建议：
注意：如果您正在考虑使用第 3 方存储库，那么您应该认真考虑如何防止这些辅助存档的意外“更新”覆盖 CentOS 的某些核心部分。一种方法是仅偶尔启用这些存档，并且通常将其禁用。参见：曼百胜
另一种方法是在 /etc/yum.repos.d/ 中找到的匹配 .conf 文件中基于每个子存档使用 except= 和 includepkgs= 选项，请参阅：man yum.conf
yum Priorities 插件可以防止第 3 方存储库替换基础软件包，或防止基础/更新替换第 3 方软件包。
第一个建议本质上是禁用 EPEL 和其他第三方存储库，然后使用类似以下内容来安装软件包：
[user@hostname ~]$ sudo dnf --enablerepo=epel install p7zip
上述是否保证CentOS的某些核心部分不会被覆盖（文档隐约暗示该问题与更新并且不一定要安装软件包）？如果是这样，那还有帮助吗？当您需要从第三方存储库更新软件包时会发生什么？
第二个建议是“在 /etc/yum.repos.d/ 中找到的匹配 .conf 文件中，在每个子存档的基础上使用 except= 和 includepkgs= 选项”。我如何知道应排除或包含哪些包以及何时排除或包含？这个建议是说我应该在从第三方存储库安装软件包之前仔细研究它吗？我并不反对了解yum和的来龙去脉dnf，但是为新用户制定一个基本有用的策略来熟悉这种方法将非常有用。
第三个建议是使用该Priorities插件，据我了解，该插件实际上内置于 CentOS 8 上的 DNF 中。优先级页面有一个非常令人不安的免责声明：
注：yum 的上游维护者 Seth Vidal 在 2009 年 9 月对“yum 优先事项”发表了以下言论：
天哪，我希望人们不要设置 yum 优先级。有太多关于优先事项的事情让我感到畏缩。可能只是它让我想起了恰当的“固定”，这让我想投掷。
这个特别的页来自一个名为“[CentOS] yum-priorities 有什么问题吗？”的线程我的担忧堆积如山：
RP Herrold 写道： > “优先级”在这一点上从 > 自我引发的依赖地狱
中倒塌并消亡，而 CentOS 因 > 背面的泼溅而受到指责。我是维基文章编辑， 在看到优先级之后，我最初添加了该警告部分， 并被推为“最佳”替代方案。 >> 事实并非如此。它更像是俄罗斯轮盘赌，无需查看 房间的状态，即可安装。 > 提到的“exclude”和“includepkg”方法 更正确， > 但也需要阅读 yum 和 rpm 手册页，并且 > 对依赖关系有一定的了解。和一个水晶球，用于预测单个名称空间和文件树中不同各方未来不协调的更改。解决这个问题的唯一方法是要么拥有一个单一的存储库，其中策略不排除任何内容，并且名称和文件是协调的，要么将包和文件名称空间委托给无法协调的存储库以防止它们发生冲突。这两种情况似乎都不太可能发生。
——
莱斯·麦克塞尔
“水晶球”真的有必要吗，还是只是为了散布恐惧？我怎么能够保证CentOS 的核心部分没有被第三方存储库覆盖，并且仍然享受这些存储库（特别是 EPEL）提供的软件包？如何安全地安装和更新第三方存储库中的软件包？ CentOS 的核心部分被覆盖时至少是显而易见的吗？