Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
69 changes: 69 additions & 0 deletions rfcs/0014-online-packaging-repo.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
# 联网构建仓库提案

- 提案发起时间:2025-06-05
- 提案拉取请求:https://github.com/deepin-community/rfcs/pull/14

## 概要

在 commercial 仓库推送无法满足离线构建条件,需要在线构建的软件包。

## 动机

当前 Deepin 的软件包构建体系主要基于离线环境,这在大多数情况下能够保证安全性和稳定性。然而,由于社区人力有限,Rust 等生态的软件包(crate)又更新频繁,依赖关系复杂,Deepin 官方仓库中的 librust 库往往更新滞后,导致开发者经常遇到依赖无法满足的情况。

在实际开发中,许多软件包需要及时获取最新的依赖才能正常构建。现有的离线构建机制无法灵活应对这类需求,导致软件包更新周期过长,影响用户体验。因此,我们需要在保证安全性的前提下,为部分软件包引入更灵活的构建机制。


## 详细设计

本提案建议为特定类别的软件包启用联网构建机制。这些软件包将不通过传统的 Open Build System (OBS) 进行构建,而是使用 GitHub Actions 等现代 CI/CD 工具完成构建流程。构建过程中允许从官方源(如 crates.io)下载必要的源代码依赖,但必须严格遵守安全规范。

构建完成后,生成的二进制包将被推送到专门的 commercial 仓库,与主仓库隔离。这种设计既满足了部分软件包的构建需求,又不会影响主仓库的稳定性和安全性。该方案特别适合那些依赖更新频繁、但自身稳定性要求较高的终端用户应用程序。

### 构建可复现性保障

所有联网构建必须确保完全可复现。例如 Rust 项目必须提供完整的 `cargo.lock` 文件锁定依赖版本。构建系统需要记录所有下载的依赖及其校验信息,确保后续构建能够还原完全相同的环境。

例如,对于 Rust 应用,我们强制要求构建脚本中必须使用 `cargo fetch --locked` `cargo build --frozen` ,禁止构建过程中更新锁文件。

### 严格的下载限制

禁止下载以下内容:

- 预编译的二进制文件
- 运行时依赖
- 仅本项目使用,可放置于离线打包仓库内的资源
- 未明确在仓库内记录哈希值并在构建时验证的资源

### 软件包准入标准

适用联网构建的软件包必须满足以下条件:

- 必须是面向终端用户的独立应用程序
- 不得作为其他软件包的构建依赖或运行时依赖

不适用该机制的软件包包括:

- 系统基础组件
- 共享库
- 任何可能被其他软件包依赖的组件

### 预期效益

实施该方案后,我们预期将获得以下改进:

1. 显著提升 Rust 等现代语言软件包的更新速度
2. 降低开发者维护软件包的负担
3. 为用户提供更丰富、更新的应用程序选择

该方案将在严格控制风险的前提下,为 deepin 生态系统带来更大的灵活性,更好地满足开发者和用户的需求。

## 可能存在的问题

在不耗费大量人力进行全面审计的前提下。我们实际上无法确保包管理器在安装依赖过程中的行为。如 Rust 平台的 `build.rs`,npm平台的 `postinstall` 等自定义脚本可能会运行各种预期外的命令。

我们尽力保证参照其他发行版的打包行为,在代码审阅的过程中发现并修正不符合本规范的行为,但无力确保仓库内的所有软件包都完全在我们的控制之下。

## 替代方案

使用自动化设施自动打包一个 Rust 应用的所有 librust 依赖至仓库,但可能会导致仓库体积失控和潜在更复杂的依赖冲突。