AskaEth/Unlucky-Launcher
1
0 Fork 0
Code Issues Pull Requests Actions 5 Packages Projects Releases Wiki Activity
Files
ab79a28b288be4a1fbdfeab0b164366ebad1ea22
Unlucky-Launcher/packaging/docs/compliance-support-boundaries.md
T
AskaEth e858664fca ci(release): M164 arm64 判定权交回编译器 + 发布名单守卫（不翻牌） 
根因（拿到的真实证据，不是猜的）：v0.2.2（run 42322062879 / job 128248713926）与 v0.2.3
（run 42429017002 / job 128573547829）两份 check-run 注解逐字一致 —— 失败步骤是第 6 步
`Windows ARM64 工具链体检`，第 7 步 `cargo build` 状态 skipped。也就是说 v0.2.1~v0.2.3 五轮
全红都红在一个**编译前的启发式探针**上，真正的编译器/链接器一次都没说话。该探针的结论还与它
自己打印的快照矛盾：`SDK Lib 版本→um 架构: 10.0.22621.0→um:[arm,arm64,x64,x86,]` 明明在，却
同时报 `kernel32=缺失`（同一个 `find -path` 模式在本地合成目录树上命中）。runner 实况是
Windows 11 Arm64 + Visual Studio 2026 镜像，`VC.Tools.ARM64` 与 `Windows11SDK.22621/26100`
都装好了，M142 的 `setup.exe modify` 反倒返回非 0。

改：
- release-build.yml：探针降级为「只取证」——vswhere 组件查询 + 各目录 `.lib` 计数 +
  arm64 `link.exe` 候选，一条 `::error::` 都不写、永不 exit 1；不再自动补装 VS。红绿只由
  cargo/链接/静态 CRT 导入表门禁决定。cargo build 步给 arm64 显式备齐工具链：
  `rustup target add aarch64-pc-windows-msvc`、`vcvarsall.bat arm64` 取 `LIB`/`INCLUDE`、
  vswhere 定位 arm64 `link.exe` 后导出 `CARGO_TARGET_AARCH64_PC_WINDOWS_MSVC_LINKER`
  （顺序不能反：只给链接器不给 LIB ⇒ LNK1181 kernel32.lib）。
- 新增 packaging/check_publish_slots.py（344 行，零依赖）：名单 ⇄ 产物**两个方向**。
  声明了缺 GUI/CLI ⇒ `::error::` + exit 1；有产物没声明 ⇒ `::warning::` 明说未发布（M142 之后
  这个方向是静默的，裁剪步只 echo 一行 drop:）。另有源码级断言（名单每项必须存在且 mode=ci、
  运行期名单必须等于文件里那行）与 8 条 `--self-test` 注入回归。
- release-publish.yml：裁剪前插一步跑那个守卫，原来内联的齐全性循环搬进脚本（一套判据一处实现）；
  重算 SHA256SUMS 的步骤只负责重算。
- release-guard.yml：PR 阶段跑守卫自测 + 源码级断言。
- 文档同步：release.yml / release-publish.yml / release-build.yml 头注释、packaging/README §12、
  §1 矩阵、§3 构建与发布、§9 支持矩阵、§7.5 arm64 取证、release-notes.md、README/README.zh-CN
  的产物矩阵与说明。口径统一为「arm64 构建取证中、未发布」，不写成已支持。

没做的（按 tower 裁决「方案乙」）：`PUBLISH_SLOTS` 本轮**不加回** arm64。arm64 从未产出过 PE、
本机也证不了，写进名单就等于拿 x64 的发布去赌它（M142 移出名单正是为避免这个事故）。下一 tag 的
CI 真出包后翻一行即可，守卫与 SHA256SUMS 自动跟着扩。

验证：workflow YAML 全部可被 PyYAML 解析；所有 `run:` 块过 `bash -n`；探针步在本机（无 VS/SDK）
实跑 exit 0 并打出实况注解；守卫 `--self-test` 8 条全绿、正反两个方向都在合成 dist 上实测过；
check_release_semantics.py（含 --self-mutation）/ release_marker / make_manifest 自检全绿；
cargo metadata 正常。**arm64 产物从未被构建过、也从未在真机跑过**——本机 `rustc --target
aarch64-pc-windows-msvc` 直接撞上没有 MSVC 链接器（git-bash 的 GNU `link` 被当成 link.exe），
`cargo check --workspace --target aarch64-pc-windows-msvc` 也死在 aws-lc-sys 的 cc-rs 阶段
（GNU host 上没有该 target 的 C 编译器）。真实结论只能等下一 tag 的 CI。
2026-11-08 08:33:44 +08:00

5.8 KiB
Raw Blame History

发行合规、支持矩阵与已知边界（M145 拆自 packaging/README.md）

本文承载原 packaging/README.md 的 §8、§9、§10，节号沿用原编号（全仓 packaging/README.md §N 这类引用照旧有效， 对照表在 packaging/README.md 的索引里）。内容一字未改、只搬家：本行以上是 M145 新增的导航说明， 以下逐行取自原文件。

8. 发行合规

  • LICENSE（Apache-2.0 全文）与 NOTICE（含 Slint Royalty-Free 2.0 义务说明）随包分发， 三份文本在 UNIX 归档内、在 Windows 侧作为并列 Release 资产。
  • Slint 的 RF 2.0 义务只跟 v0.1.0 那批资产：当时关于页有 AboutSlint 部件、选的是不触发 GPL 分支的 RF 分支 （见 deny.toml 的许可证白名单注释）。现役 iced UI 里没有、也不需要任何 Slint 部件。
  • M118 后这条义务只跟着已发布的 v0.1.0 资产走：crates/app 已被 workspace exclude，发布矩阵里再没有链接 Slint 的二进制，新的 iced 版产物不链接 Slint；deny.toml 那条 RF-2.0 allow 因此暂时是死条目（不删，留给将来真有别的路径引入 Slint 时兜底）。
  • README.md（英文主版）随包分发；中文版 README.zh-CN.md 留在仓库不进包（避免包体噪音）。
  • 依赖许可门禁不变：deny.toml 白名单（Apache-2.0 / MIT / BSD / Zlib / BSL-1.0 / ISC / CC0 / Unlicense / Unicode-3.0 / CDLA-Permissive-2.0 / Slint-RF-2.0）。发布任务不新增任何依赖。
  • 发布产物不含游戏本体、不含 JRE、不含任何账号数据；ull/GUI 的数据目录在用户侧生成。

9. 支持矩阵（对外口径，与 release-notes 模板逐行一致）

平台 本版发布 级别 运行时要求
Windows 10/11 x64 ✅ 一等 无（UCRT 系统自带）
Windows 11 ARM64 ❌ 不发布（构建取证中） 一等（启动器产物） 无额外库；启动器原生运行，游戏本体走系统 x64 模拟层 + x64 JDK
macOS 12+（arm64 / x64） ❌ 不构建 一等（未真机验证） 无第三方库；未签名需去 quarantine
Linux x64 X11 ❌ 不构建 一等（未真机验证） glibc 2.35+、xkbcommon、fontconfig、libGL、xcb
Linux x64 Wayland ❌ 不构建 支持 上述 + wayland-client
Linux arm64 X11 ❌ 不构建 一等（未真机验证） glibc 2.35+（ubuntu-22.04-arm 原生构建，与 x64 同地板）、xkbcommon、fontconfig、libGL、xcb
Linux arm64 Wayland ❌ 不构建 支持 上述 + wayland-client
Windows 8.1/8/7 — 不支持 基线已上调（D21）
Android Termux + X11 — 试验级（不承诺） CLI 与 GUI 均需源码自建；GUI 已在单机真机验证两条路径各一次（CPU 软渲染 + 自编 Mesa/turnip GPU 加速，配方见 packaging/docs/termux-glibc-build.md、证据见 README.termux.md），不在本发布矩阵内

packaging/release-notes.md 的 "Support matrix" 表与上表逐行对应（英文版同样带 published / not published 一列，Termux 行标注 experimental）——改一边必须同步另一边，否则标题里的"一致"就是假话。

两个 arm64 槽位都是正式矩阵槽位（不是 Termux 那种源码自建旁路），但本版两个都不发布：windows-arm64 照构建取证 （红了不挡 x64 发布），linux-arm64 连构建都不跑；发布开关是 release-publish.yml 的 PUBLISH_SLOTS（当前只有 windows-x64）。

（M164）windows-arm64 为什么还没进名单：它 v0.2.1~v0.2.3 的红全部红在一个编译前体检步（find 猜 SDK 的 um/arm64/kernel32.lib），cargo build 一次都没跑过；M164 把那个门禁降级为只取证、判定权交回编译器，但「能不能 出 PE」只能由下一 tag 的 CI 证明。名单 ⇄ 产物的两个方向现在都有守卫（packaging/check_publish_slots.py）： 声明了缺产物 ⇒ 红，有产物没声明 ⇒ ::warning:: 明说未发布 —— 所以那次 CI 真出包之后，翻一行名单即可。

10. 已知边界 / 后续

  1. GUI 的 --version 已解决（M82）：现在命中子命令分发，输出与 ull --version 同一条版本 + 系统摘要后退出， 不再开窗；§7.2 里「无输出、8 秒后被 timeout 杀掉」那行是改之前的记录，留作对照。
  2. 签名/公证：Windows 无 Authenticode、macOS 无 codesign/notarize（都要证书/开发者账号）， 当前以 SHA256SUMS + Release 说明作为完整性参考。
  3. macOS .app bundle / .dmg：与单文件承诺冲突，暂不做；若用户要 Dock 图标再单开 mission。
  4. Linux musl 静态版：可彻底摆脱 glibc 地板，但现役 iced 版（winit + wgpu）在 musl 上的可行性未验证，未纳入本矩阵。
  5. ull 已随包（M82 起）：每个槽位与 GUI 并列发一份裸 ull，进同一份 SHA256SUMS.txt，矩阵 完整性检查按「GUI 与 CLI 各自都要有」分开查（release.yml）。等 CI 首跑确认这条在真流水线上有效。
  6. 本机 GNU 链接器的已知无害告警：cargo build --release（GNU 工具链）会打一行 warning: linker stderr: corrupt .drectve at end of def file（MinGW ld 的老式抱怨，不影响产物；CI 的 MSVC 槽位没有）。
  7. 两个 arm64 槽位本机跑不了：本机是 x64 Windows，既无 ARM 机器也无 MSVC 的 ARM64 链接库组合， windows-arm64 / linux-arm64 的真实产物只能由 CI 出（前者靠 dumpbin -dependents 的静态 CRT 门禁 + 架构校验，后者在 ubuntu-22.04-arm 上真跑 ull --version 冒烟）；本机能做且已做的是脚本层 取证（§7.5：宿主判定注入、可执行文件头识别、把真 exe 的 PE 机器码改成 ARM64 当 stub 走完全流程）。
Reference in new issue View Git Blame Copy Permalink