EL 10：模块流退场
EL 8 引入、争议不断的 AppStream 模块流（module streams），在 EL 10 正式退场：仓库不再分发 modular 内容，dnf module 命令虽然还在，但只会给出弃用警告。“用模块流选软件版本”的时代结束了，取而代之的是带版本号的普通包、第三方源与容器。
这是什么变化
Section titled “这是什么变化”模块流的设计初衷：让 AppStream 里同一个软件（如 PHP、PostgreSQL、Node.js）同时提供多个大版本，用 dnf module enable php:8.1 选择。实践中它带来了仓库元数据膨胀、镜像与 Kickstart 复杂度、以及”模块流生命周期比发行版短”的维护问题。
EL 10 的选择是不再分发 modular 内容：
dnf module list/dnf module enable输出弃用警告且无可用模块；- 多版本软件改为直接提供带版本号的包名（仓库实际提供为准），或由 EPEL / 上游源 / 容器镜像承担。
EL 8 → EL 9 → EL 10 对比
Section titled “EL 8 → EL 9 → EL 10 对比”| 项 | EL 8 | EL 9 | EL 10 |
|---|---|---|---|
| modular 内容 | 引入并广泛使用 | 继续提供，范围收窄 | 不再分发 |
dnf module | 完整可用 | 可用 | 仅剩弃用警告 |
| 多版本应用获取方式 | 模块流 | 模块流 + 版本化包 | 版本化包 / 第三方源 / 容器 |
- 依赖
dnf module的自动化：Kickstart 的module --name=…行、Ansible / shell 脚本里的dnf module enable，在 EL 10 上全部失效或产生告警，需提前清理。 - 多版本需求：如需要非默认版本的 PostgreSQL / Redis / PHP，改查 EPEL 与第三方源 或容器方案；部分软件（如 Redis）在第三方源中已改为版本化包名。
- 从 EL 8/9 升级：已 enable 的模块流不会”迁移”，升级后对应软件以 EL 10 仓库提供的版本为准，需逐一确认。
dnf module list --enableddnf module list # 仅弃用警告，无模块内容- 升级前导出已启用模块清单；
- 为每个模块流确定 EL 10 替代（默认版本包 / 版本化包名 / 第三方源 / 容器）；
- 清理自动化脚本与镜像模板中的
module指令； - 升级后按新方式验证服务版本。
- EL 8：BaseOS 与 AppStream — 模块化诞生时的仓库设计
- DNF 基础 — DNF 4.20 与日常命令
- EPEL 与第三方源 — 多版本软件的现去向
- EL 9 → EL 10 升级 — 完整升级步骤