Stream 上的模块流与应用流

This content is not available in your language yet.

模块流与应用流是 CentOS Stream 里最容易被误解的一层：它看起来像「同一软件的多个版本并存」，实际是仓库元数据里的一组可选流。本页讲清它由什么定义、怎么选、以及变更该从哪里跟。

先把用词定下来

为避免歧义，本页按下面的口径用词（这是本页的定义，不是官方术语表）：

包名：你实际安装的那个东西的名字，比如一个数据库或一门语言的运行时；
流：同一个包名下的不同版本线，一条流代表一条维护方向；
默认流：你没有显式选择时生效的那条流。

模块流的内容由 AppStream 仓库定义

CentOS Stream 提供 AppStream 仓库：本次核对实测 10-stream 的 AppStream 元数据可以从官方镜像取到，模块流的内容以该仓库的元数据为准。所以「选流」在操作上就是读改这份元数据——用 dnf module list 看有哪些流、用 dnf module enable 启用某个流、用 dnf module switch-to 在流之间切换、用 dnf module reset 回到默认流。

列出与启用：把「读元数据」变成动作

操作顺序可以固定成三步，无论你用的是哪条流：

先读：确认当前跟的是哪条流，再决定要不要动它；读的动作不改系统状态；
再选：只有在需要一个非默认版本线时才启用某条流，并把「为什么选它」写进变更记录；
后验：切换之后按业务用例验证一遍，而不是只看包能不能装上。

锁定与切换流：先留回滚点

切换流会改变之后解析到的内容，所以它是一次变更，不是一次查询。动手前确认三件事：

切换会影响哪些包：把当前跟着这条流的包列出来，看看上面跑着什么服务；
回退走哪条路：快照、旧机器或重建，三条路至少留一条能走通；
观察窗多长：至少覆盖一个完整业务周期，再决定是否把这次切换固化进基线。

与旧 SCL 的差异：本次核对能说到哪

Software Collections（SCL）与模块流是两代不同的内容组织方式。本次核对没有取得把某个 SCL 集合对应到某条模块流的官方说明，因此本页不做映射表，也不写「把 SCL 换成模块流」的步骤。

需要对照时，能依靠的仍然是同一份东西：仓库元数据（有哪些流、默认流是哪个）与 release notes（这轮改了什么）。这也正是下面两节要讲的跟踪方式。

变更从哪看：Stream 10 的 release notes

官方下载页对 CentOS Stream 10 的说明是：它的 release notes 会持续更新，以纳入问题并吸收用户反馈。这句话只覆盖 Stream 10——本次核对没有把它登记为所有 Stream 版本的通用表述。

把变更跟踪放进流程（本站实践建议）

以下做法是本站的实践建议，不是官方结论：把目标版本的 release notes 纳入变更评审，模块流或应用流的变更先在那里确认，再决定是否在自有环境里跟随。

具体可以落到三条纪律上：

每次变更前看一眼：把 release notes 放进变更单的必填项，而不是出事之后才去翻；
只跟随与自己有关的条目：把当前启用的流列成清单，逐条对照 release notes，避免「全都跟」或「全都不跟」；
把结论写回基线：决定跟随或跳过的理由记录下来，下次同一条流再变时不必重新讨论。

常见误解

「模块流是系统版本自带的，不用管」：模块流的内容以仓库元数据为准，应该按仓库去看，而不是凭记忆；
「release notes 只在装机时看一次」：上面那条官方说明强调的是持续更新，跟踪方式要配得上这个节奏；
「SCL 怎么用，模块流就怎么用」：本次核对没有取得两者对应关系的官方说明，照搬旧做法没有依据。