为什么RHEL 9中模块那么少?

许多人已注意到红帽企业Linux（RHEL）9里缺模块。在Beta版本中只有一个模块，在初始版本中一个都没有，这让人质疑模块的现状和总体计划。 

本文，我们将深入研究一些关于模块是如何使用的历史，在最初采用它们时学到的一些经验教训，以及对RHEL 9里模块的期待。

应用流

在RHEL 8中，以应用流的形式引入了一个新概念。应用流的一个常见用例是，允许以比以前使用RHEL版本更快的速度引入流行应用的新版本。这些是作为新流引入的，支持预定义的时间段。

这种类型的应用流发布导致许多人推断模块是一个且相同的。实际上，模块是一种封装格式技术。它们只是应用流可以采用的形式之一，还有相当多的其他形式，包括: 

传统的RPM

模块 

Flatpaks 

软件集合 

为给定的应用流选择的打包格式主要是基于组件的最佳匹配、支持的持续时间和上游社区计划。 

当模块是最适合这项工作的技术时，就会使用它们。如果有另一种格式更有利，那就用。

模块

如上所述，一个常见的需求是允许在重叠的时间段支持不同的应用流。在传统RPM情况下，这很难实现，因为要选择最新版本。这是必须避免的，因为许多主要版本的软件本身并不是向后兼容的。如果日常更新期间在主要版本之间更新数据库，这可能意味着停机，或更糟的情况。 

在RHEL 7中，首选的格式是软件集合（SCL）。如果需要同时安装多个版本，SCL很好用。如果想要选择一个特定版本作为唯一安装的版本，那么SCL可能不是最佳的选择。 

当不需要同时安装或运行多个版本时，模块是理想的选择。通过将软件的特定主要版本作为一个模块构建在一起，并增强包管理工具以理解这些版本，可以同时获得多个版本，最终用户可以在维护系统更新时选择他们需要的版本。不需要使用“scl enable”命令，因为使用的版本在安装时已选择!

这就引出了一些问题。 

为什么RHEL 9中模块那么少?

客户对应用流的反应很积极，但总有改进的地方。早期确定的改进之一是尽可能早地确定完整的生命流（与RHEL 9相同的生命周期），让客户尽早将这种类型的低层级计划信息合并到他们的采用计划中。 

另一个改进是希望在RHEL发行版的整个生命周期中支持哪些版本，与支持哪些版本的持续时间较短之间有一个简单的区别。

为了满足这一需求，在可能的情况下，将特定版本确定为应用的完整版本，以进行初始发布。第二个改进是，这个版本是作为传统RPM而不是模块发布的。这意味着选择完全依赖于这些完整生命周期的应用流的用户和开发人员，可以忽略特定于模块的工具和流程。

在RHEL 9中会有模块吗?

有的。随着应用流的其他主要版本被确定为必要的，后续的RHEL 9版本将发布支持时间更短的其他应用流。在版本之间存在重叠和冲突的情况下，模块将在最适合应用时使用。 

这是怎么做到的呢?

RHEL 9将不包括任何默认的模块流。在没有启用的情况下，模块流将取代传统的RPM。因此，通过以传统RPM的形式发布单个流，但稍后提供模块化流，最终将得到最佳结果。 

当没有特别启用时，将使用传统的RPM版本，通过进一步简化包管理过程来简化用户体验。 

不断改进

在RHEL 9中，我们根据对软件集合、RHEL 8中模块的经验，以及来自客户的反馈，改进了模块用户体验。

上一条：Quest:应用程序现代化

下一条：深信服提醒 假期来临，更要做好勒索病毒防护