chore: 身份对齐上游 —— ffmpeg:ffmpeg@8.1.2

[Sunrisepeak]

生态规范化第二例(第一例:imgui-m#12)。规则与全量迁移表见 mcpp-index#163。

版本:0.0.3 → 8.1.2

0.0.3 是打包计数。真实答案一直写在同一个文件里:

[dependencies]
compat.ffmpeg = "8.1.2"

命名空间:mcpplibs → ffmpeg

mcpplibs 是 mcpp 的默认命名空间(kDefaultNamespace),不是"上游是谁"的答案。FFmpeg 是 FFmpeg 的,本仓库只是在它之上加 import ffmpeg.av; 这一层。

为什么同批

裸名梯级 (mcpplibs, X) → (compat, X):只改版本会让 ffmpeg = "8.1.2" 在第一级就命中本包,而现在它落到的是 compat.ffmpeg(2281 TU 的源码构建包)—— 静默换包。迁出默认命名空间后第一级永远落空,行为不变。

验证

本机确认 manifest 解析与新身份生效(Compiling ffmpeg v8.1.2);完整构建(2281 TU + NASM)交给 CI,本机没有 compat.ffmpeg 缓存。

附带

模板里命名空间是硬编码的 —— mcpp 的模板变量只有 {{self.name}} 与 {{self.version}},没有 {{self.namespace}},非默认命名空间的包因此拼不出自己的依赖声明。这会打到每一个带模板的待迁包。

[Sunrisepeak]

更正:PR 描述里「为什么两件事必须同批」那一节的论据是错的

我在描述里写:

tests/examples/imgui 写的是裸名 imgui = "1.92.8",只改版本会让它在第一级命中本包,静默换包。

那个成员写的是限定名,带着段头看是 [dependencies.compat] imgui = "1.92.8"。我只看了 grep 出来的那一行,没看它属于哪个 [dependencies.*] 段。既然明写了 compat,就没有东西能把它换掉 —— 那条"静默换包"的风险不存在。

真正成立的后果是另一条:module 层的成员用的才是裸名(imgui-module 的 imgui = "0.0.1"、ffmpeg-module 的 ffmpeg = "0.0.3" 等),迁出默认命名空间后它们会响亮地解析失败,索引 PR 里必须一并改成限定写法。比我原先描述的风险小得多,也好查得多。

判据与本 PR 的改动都不依赖那条错误论据:命名空间说的是这个库是谁的,版本说的是你拿到的是哪一版上游。同批做仍然对,理由退化成朴素的一条 —— 一次迁移比两次迁移少让用户改一遍写法。

详见 mcpp-index#163 的更正。