Independent precompiled LibreOffice package
独立的预编译 LibreOffice 包
Compiling LibreOffice inside ordinary DSH builds would require every contributor and CI job to acquire its toolchain and repeat a large native build. Desktop also needs immutable engine resources that can travel with its offline installation material.
English
Problem
Compiling LibreOffice inside ordinary DSH builds would require every contributor and CI job to acquire its toolchain and repeat a large native build. Desktop also needs immutable engine resources that can travel with its offline installation material.
Decision
The engine package has its own version and an asset-only manifest export. Its source directory stays outside the main pnpm workspace. Installation has no lifecycle hook, and packaging verifies an existing successful build without compiling. The release workflow compiles only on explicit dispatch; publication requires a matching engine version tag and the protected npm environment.
Each tarball contains the engine manifest and assets, corresponding source pins, patches, full source diff, and the built distribution's license and notices. Packaging rejects mismatched build receipts, modified assets, unlisted engine files, missing notices, and bundled fonts. A failure never triggers compilation automatically.
The local preview decision continues to own conversion and explicit artifact configuration. This change establishes release machinery; it does not add an unpublished engine dependency to DSH. The existing Desktop package set remains the intended carrier for a future fixed-version dependency and its offline seed.
Alternatives considered
Compile during ordinary builds or package installation. This puts engine toolchain availability and compilation cost on every consumer, even when the engine version has not changed.
Extract a general Node conversion library. Font handling, Worker ownership, and the conversion API can remain with the provider. Moving them is unnecessary to distribute precompiled assets or isolate compilation from DSH CI.
Link the engine source as a workspace dependency. Workspace linking would replace a published precompiled package with a source directory that lacks its engine files.
Consequences
The engine can be compiled and versioned independently of DSH. The package exposes files rather than a conversion API; the provider retains runtime ownership. Ordinary builds remain free of LibreOffice compilation, as checked by the packaging tests.
Initial publication and fixed-version consumer integration remain incomplete. A source tree that differs from its recorded recipe cannot produce a release tarball. Real-engine conversion, installation from the packed package, and Desktop offline seed qualification must accompany the first consumed engine release.
中文
问题
在普通 DSH 构建中编译 LibreOffice，会要求每个贡献者和 CI job 获取工具链并重复执行大型本机构建。Desktop 也需要能随离线安装材料分发的不可变引擎资源。
决策
引擎包采用独立版本，只导出产物清单。源码目录不属于主 pnpm workspace。安装没有生命周期 hook，打包只校验已有的成功构建，不执行编译。发布工作流仅在明确调度时编译；发布要求匹配的引擎版本 tag 和受保护的 npm 环境。
每个 tarball 包含引擎清单和产物、对应的源码版本、补丁、完整源码差异，以及构建发行物的许可证和声明。打包拒绝不匹配的构建记录、被修改的产物、未列入清单的引擎文件、缺失的声明和内置字体。失败不会自动触发编译。
本地预览决策继续负责转换与显式产物配置。此改动建立发布机制，不向 DSH 添加尚未发布的引擎依赖。现有 Desktop 包集合仍是未来固定版本依赖及其离线 seed 的预期载体。
考虑过的替代方案
在普通构建或包安装期间编译。 即使引擎版本没有变化，每个消费方也要承担工具链可用性要求和编译开销。
抽出通用 Node 转换库。 字体处理、Worker 所有权和转换 API 可以继续由提供方负责。分发预编译产物及将编译与 DSH CI 隔离不需要迁移这些逻辑。
将引擎源码链接为 workspace 依赖。 工作区链接会把已发布的预编译包替换为缺少引擎文件的源码目录。
影响
引擎可以独立于 DSH 编译和发布版本。包暴露文件而非转换 API；提供方保留运行时所有权。打包测试检查普通构建不编译 LibreOffice。
首次发布和固定版本消费方接入尚未完成。与记录的配方不一致的源码树不能产生发布 tarball。首个被消费的引擎发行版必须同时完成真实引擎转换、打包安装，以及 Desktop 离线 seed 验证。