Skip to content

预告：l3backend 将并入 l3kernel #1074

Closed
Task
#1084
Closed
预告：l3backend 将并入 l3kernel#1074
Task
#1084
Labels
github_actionsPull requests that update GitHub Actions code

Description

@muzimuzhi
muzimuzhi
opened on Aug 12, 2026

l3backend 已并入 l3kernel（latex3/latex3#1948 ）， 下一次 l3kernel 稳定版发布后，将没有 l3backend 这个包。

届时，#1054 想规避的问题（l3kernel 与 l3backend 版本错配）将在 CI 消失。可能需要调整 #1054 引入的修改。

目前，l3kernel-dev 2026-08-10 已发布（ctan-ann）：l3backend-dev 并入 l3kernel-dev，同时前者移除。

$ tlmgr info l3backend-dev
tlmgr: cannot find package l3backend-dev, searching for other matches:

Packages containing `l3backend-dev' in their title/description:
l3kernel-dev - Development pre-release of l3kernel

Packages containing files matching `l3backend-dev':

Activity

  1. github-actions commented on Aug 12, 2026

    @github-actions
    github-actionsbot
    on Aug 12, 2026 – with GitHub Actions
    Contributor

    💬 回答 #1074

    需要跟进，但现在不宜仅依据开发版变更立即调整。

    当前 scripts/sync-l3backend.sh 是为解决 TeX Live 中 l3kernel 与独立 l3backend 日期不一致而加入的临时措施。脚本已经规定撤除条件：两者日期一致时输出 notice，并提示删除脚本及其调用。等包含该合并改动的稳定版发布并进入项目使用的 TeX Live 分发后，应先核对实际安装布局和版本日期，再删除或改写该措施。

    届时至少需要检查：

    • l3backend-*.def 是否仍作为可单独定位的文件提供；
    • scripts/sync-l3backend.sh 的日期探测是否仍成立；
    • 回归测试、文档构建和发布构建中的三处调用是否可以一并删除；
    • 删除后 XeTeX、dvipdfmx 的颜色输出回归和生成 PDF 是否正常。

    这属于依赖稳定版发布后的维护事项，目前没有现存故障，也没有必要提前修改。

    📖 技术细节

    相关代码：

    如果合并后的稳定版不再发布独立的 l3backend.zip，现有脚本的下载分支将失去意义；不过只要分发中的日期已经一致，脚本会在下载前直接退出。因此可以等待稳定版和 TeX Live 分发实际同步后，再以 CI 环境中的解析结果决定最终改动。

    由 codex / gpt-5.6-sol 生成；本流程只分析，不自动修改代码。

  2. myhsia
    added the
    Task
    issue type on Aug 13, 2026
  3. myhsia
    added
    github_actionsPull requests that update GitHub Actions code
    on Aug 13, 2026

  4. Liam0205 commented on Aug 13, 2026

    @Liam0205
    Liam0205
    on Aug 13, 2026
    Contributor

    感谢预告。按这条线索做了一轮实测，把结论和复现步骤留在这里，供决定何时动手时参考。

    结论先说

    我们的 CI 当前完全不受影响，而且合并本身会让 scripts/sync-l3backend.sh 自动空转——这正是它的设计意图。但有一个窄窗口会让它给出误导性的失败信息，值得先修掉。

    实测到的四点

    1. 改动要等下一个 stable 才会打到我们

    CI pin 的是 TL 2026 stable（test.yml 顶层 TL_VERSION: '2026'，透传给所有 caller）。stable 通道里 l3backend 仍是独立包：

    $ curl -sS 'https://ctan.org/json/2.0/pkg/l3backend' | ...
id: l3backend   version: {'number': '', 'date': '2026-07-20'}

$ tlmgr info l3backend
package:   l3backend
category:  Package
revision:  78544

    macros/latex/required/l3backend.zip 现在也仍然下得到（904508 字节，unzip -t 通过），脚本端到端可用。

    2. .def 文件名不变，只是改由 l3kernel 提供

    这是最关键的一点，直接决定脚本会不会崩。下载 l3kernel-dev.tds.zip（2026-08-10，已完成合并）解开看实际布局：

    tex/latex-dev/l3kernel/l3backend-pdftex.def
tex/latex-dev/l3kernel/l3backend-xetex.def
tex/latex-dev/l3kernel/l3backend-dvipdfmx.def
tex/latex-dev/l3kernel/l3backend-luatex.def
tex/latex-dev/l3kernel/l3backend-dvips.def
tex/latex-dev/l3kernel/l3backend-dvisvgm.def
tex/latex-dev/l3kernel/l3backend-hitex.def

    l3backend.ins 也仍在包内（与 latex3#1948 的说明一致）。所以脚本里两处 kpsewhich l3backend-pdftex.def（日期探测与生效校验）合并后依然能命中，不会因找不到文件而失败。

    3. 合并后错配判断天然成立，脚本自动空转

    同一份 tds 里两个探测点的日期：

    expl3.sty            : 2026-08-10
l3backend-pdftex.def : 2026-08-10

    同包同发布，日期必然一致 → 脚本的相等分支成立 → 打 notice 后 exit 0。也就是说 #1054 的撤除判据（「两个日期一致」）在合并后恰好也成立，撤除动作本身不用改。

    不过撤除的理由变了：不再是「上游把版本对齐了」（当下对齐，将来仍可能再错开），而是「这个包不存在了，错配从此不可能发生」——后者是永久性的。这一点值得写进脚本注释，否则日后看到 notice 的人无法判断是哪种情形。

    4. 一个会误报的窄窗口（建议先修这个）

    把脚本里三个 mirror URL 改成不存在的路径跑一遍，模拟「包已从 CTAN 消失」：

    ::warning::l3kernel (2026-07-20) 与 l3backend (2026-02-18) 日期不一致, 从 CTAN 取匹配版本
尝试 .../l3backend-GONE.zip
curl: (22) The requested URL returned error: 404
（三个 mirror 依次失败）
::error::所有 mirror 均无法下载 l3backend; 这是网络/镜像问题, 重跑本 job 即可

    这条消息会把「包已不存在」误导成「网络抖动，重跑就好」，让人反复重跑徒劳的 job。

    按第 3 点，正常情况下走不到这个分支。但两者组合出一个窄窗口：若某次 stable 发布出现「l3kernel 已合并、而分发通道里残留旧 l3backend」的过渡态，日期不一致会成立、下载又必然失败，正好撞进这条误导信息。

    建议的处置

    分两步：

    现在（低风险）：在下载失败分支加一步判别——先探 l3backend 是否还存在于 CTAN，若已不在则打印「已并入 l3kernel，请删除本脚本及其调用」并 exit 0，而不是 exit 1 报网络错。同时把撤除条件补上「包已消失」这第二种情形。

    将来（stable 发布后）：删 scripts/sync-l3backend.sh 及三处调用（_test-package.yml、_check-doc-package.yml、release.yml），另有 check-doc.yml / test.yml 里 4 处 paths 白名单条目，以及 llmdoc 若干处文档需同步。

    另一件不随本次变动消失的事

    #1054 的「未包含」里那条仍然成立，而且更值得做：scripts/verify-doc-output.sh 只有容器级判据（文件存在、%PDF 魔数、大于 1024 字节），对「编译成功但正文被污染」是盲的——l3backend 错配当初正是靠人眼看版面才发现的，l3build doc 全程 exit 0。

    这个盲区不随 l3backend 消失而消失，它是下一个同类上游问题的敞口。

    以上除第 1 点的时间线判断外，其余均为本地实测（TL 2026 stable + 下载 dev tds 对照 + 404 模拟），命令与输出如上，可复现。

  5. Liam0205 commented on Aug 18, 2026

    @Liam0205
    Liam0205
    on Aug 18, 2026
    Contributor

    稳定版已经上 CTAN 了，把当前各通道的状态和时间窗口登记一下。结论是暂时不动，等 TL 跟进。

    触发点

    CTAN update: l3kernel（2026-08-18
    发布，版本 2026-08-10），公告正文：

    [2026-08-10]

    Changed

    • Integrate l3backend files into l3kernel distribution

    也就是说这条 issue 预告的合并已经落到 stable 通道，不再只是 dev。

    各通道现状（今日实测）

    通道 l3kernel l3backend
    CTAN 2026-08-10（含合并） 已移除 —— ctan.org/json/2.0/pkg/l3backend 返回 id: None；macros/latex/required/l3backend.zip HTTP 404
    tlnet（CI 与本地实际使用） 2026-07-20 仍在，2026-07-20，l3backend.tar.xz HTTP 200
    本地 TL 2026 2026-07-20 2026-07-20（kpsewhich l3backend-pdftex.def 命中 texmf/tex/latex/l3backend/）

    所以 CI 目前不受影响：tlnet 两个包日期一致且都还在，scripts/sync-l3backend.sh 走相等分支、
    打 notice 后 exit 0。今天实跑确认：

    l3kernel:  2026-07-20
l3backend: 2026-07-20
::notice::l3kernel 与 l3backend 日期一致, 无需 workaround; scripts/sync-l3backend.sh 及其调用可以删除了

    一个此前没查过的事实

    CTAN 的 l3kernel.zip（14 MB）里只有 .dtx 源码和 l3backend.ins，没有解包好的 .def：

    l3kernel/l3backend-basics.dtx
l3kernel/l3backend-color.dtx
...
l3kernel/l3backend.ins

    l3backend-*.def 是 TeX Live 打包时由 .ins 生成的。所以「.def 文件名会不会消失、还能不能
    被 kpsewhich 找到」这件事，取决于 TL 怎么打包合并后的 l3kernel，而不取决于 CTAN。目前 tlnet 的
    l3kernel.tar.xz 里还没有任何 l3backend-*.def，.def 仍由独立的 l3backend 包提供。

    这一点直接决定脚本会不会崩：脚本有两处 kpsewhich l3backend-pdftex.def（日期探测与生效校验），
    只要 TL 仍以某种方式提供该文件名，就不会因找不到文件而失败。

    时间窗口：来得及，不必赶

    CI 的 TL 缓存 key 是 ISO 年-周（test.yml 的 TZ=UTC date +'%G-W%V'）。今天是
    2026-W34，下一次失效在下周一 2026-08-24（翻到 2026-W35）才发生。TL 通常一两天内跟进
    上游更新，所以到那时大概率已经追平。

    在缓存失效前，CI continue 用现有 TEXDIR，两个日期都是 07-20，脚本恒空转。

    因此的处置计划

    现在什么都不做。 等 TL 跟进后再一次性处理，免得按当前中间态改完又要改一遍。

    下周一缓存失效时观察两种结果：

    1. TL 已追平（预期）—— tlnet 的 l3kernel 到 08-10 且 .def 由它提供。此时两个日期天然一致，
      脚本继续空转并打 notice，可以按 notice 的提示删除脚本及三处调用（_test-package.yml、
      _check-doc-package.yml、release.yml），外加 check-doc.yml／test.yml 里 4 处 paths 白名单
      条目与若干 llmdoc 记载。

    2. TL 仍未跟进、且出现过渡态 —— 即 tlnet 的 l3kernel 已到 08-10 而 l3backend 还是旧日期。
      这时日期不一致成立、脚本进入下载分支，而三个 mirror 必然全部 404（包已从 CTAN 移除），于是会
      报出误导性的错误：

      ::error::所有 mirror 均无法下载 l3backend; 这是网络/镜像问题, 重跑本 job 即可

      这条消息会让人反复重跑徒劳的 job，而真相是「包已经不存在了，该删脚本」。若真撞上这一态，
      先修这条消息      ：在下载失败分支加一步判别，探测 l3backend 是否还在 CTAN，已不在就打印
      「已并入 l3kernel，请删除本脚本及其调用」并 exit 0。

    另一件不随本次变动消失的事

    上一条评论里提到的那点仍然成立、也仍未做：scripts/verify-doc-output.sh 只有容器级判据（文件
    存在、%PDF 魔数、大于 1024 字节），对「编译成功但正文被污染」是盲的——l3backend 错配当初正是
    靠人眼看版面才发现的，l3build doc 全程 exit 0。

    这个盲区与 l3backend 是否存在无关，它是下一个同类上游问题的敞口，比本条 issue 更值得排期。

  6. Liam0205
    added 3 commits that reference this issue on Aug 19, 2026

    docs(llmdoc): 修 index 与 kpse 文档里指向已删措施的失效表述 (#1074)

    2e2eed7

    docs(llmdoc): 修 index 里 release 流程摘要仍称含第 6 步 (#1074)

    f2bffcb

    chore(ci): 撤除 l3backend 版本错配的 workaround (#1074)

    5530d92
  7. Liam0205
    closed this as completedin #1084on Aug 19, 2026
  8. Liam0205
    added 3 commits that reference this issue on Aug 19, 2026

    docs(llmdoc): 记录 #1074 撤除 workaround 的判据与三层教训

    4a5c72c

    docs(llmdoc): 修 index 与 kpse 文档里指向已删措施的失效表述 (#1074)

    1ac4c77

    docs(llmdoc): 修 index 里 release 流程摘要仍称含第 6 步 (#1074)

    4d74db4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    github_actionsPull requests that update GitHub Actions code

    Type

    Task

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions