From a54b1959d93a3ee803e5d89aac512f43920564a9 Mon Sep 17 00:00:00 2001 From: Yukari Chiba Date: Wed, 12 Feb 2025 17:53:40 +0800 Subject: [PATCH] feat: add rfc 0013 electron packaging --- rfcs/0013-electron.md | 50 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 rfcs/0013-electron.md diff --git a/rfcs/0013-electron.md b/rfcs/0013-electron.md new file mode 100644 index 0000000..eb5e7c7 --- /dev/null +++ b/rfcs/0013-electron.md @@ -0,0 +1,50 @@ +# 标题：为 deepin 引入 electron 运行时软件包及应用维护提案 + +- 提案发起时间：2025-02-12 +- 提案拉取请求：https://github.com/deepin-community/rfcs/pull/13 + +## 概要 + +本提案旨在向 deepin 仓库引入共享的 electron 运行时软件包，并为依赖这些运行时的应用程序定义打包规范。 + +## 动机 + +目前，deepin 官方仓库未提供 electron 运行时软件包，debian 社区也没有打包 electron 运行时，这导致仓库里无法打包任何基于 electron 的应用。 + +当前 deepin 应用商店已上架的 electron 应用普遍采用捆绑运行时的模式发布，此模式导致了显著的磁盘空间与带宽冗余，并分散了维护责任。安全更新的责任被转嫁给各应用开发者，使得漏洞响应难以统一和及时。 + +本提案通过引入由社区统一维护的共享 electron 运行时，旨在解决上述问题，从而实现资源优化、提升安全响应效率，并为开发者提供一个稳定、一致的应用运行环境。 + +## 详细设计 + +### 1. electron 运行时软件包命名和版本管理 + +运行时软件包将采用主版本号命名，格式为 `electron-` （例如 `electron-25`、`electron-26`、`electron-27`）。系统将支持多个主版本的运行时共存，以满足不同应用的兼容性需求。为确保依赖的稳定性，将不设立指向默认版本的通用元软件包（`electron`）。应用程序必须在其依赖中显式声明所需运行时的具体主版本。 + +### 2. electron 运行时软件包的依赖和内容 + +每个运行时软件包将包含运行应用所需的核心二进制文件、库及资源。构建时，其依赖的 Node.js 将被静态链接或内部捆绑，以确保运行环境的自洽性。因此，最终生成的软件包自身将不依赖于系统仓库中的 `nodejs` 或 `npm` 包。 + +### 3. electron 应用程序打包方式 + +应用程序开发者在打包时，须在其 `debian/control` 文件中明确声明对特定主版本运行时的依赖，例如 `Depends: electron29`。软件包内容应仅包含应用自身代码与资源（如 `app.asar`），不再捆绑 electron 二进制文件。应用的启动脚本需相应修改，以调用系统路径下的共享运行时，例如 `exec /usr/bin/electron29 /usr/lib/app-name/ "$@"`。 + +### 4. 版本更新和维护 + +新版本的引入将紧随上游 electron 的稳定版（Stable）发布节奏。 + +对于安全更新，社区在收到上游安全公告后，会及时构建并推送修复版本至仓库，并设置 CI 定期检查现有的各版本 electron 包是否有安全更新。 + +社区将评估并选择一个稳定版本，作为长期支持（LTS）版本进行维护。当某一版本被上游停止支持后，社区将在提供合理的迁移缓冲期后，将其提前通知开发者，然后从仓库中移除。 + +## 提案弊端 + +本提案需要社区持续维护多个 electron 版本，特别是在响应安全更新时需要及时跟进。 + +## 遗留问题 + +- 初期应引入哪些 electron 主版本以满足当前核心应用的需求？ + +## 替代方案 + +唯一的替代方案是维持现状，即由各应用自行捆绑运行时。如“动机”一节所述，此方案在资源利用、安全维护和生态一致性方面存在明显缺陷，不利于社区的长期发展。