feat: add rfc 0013 electron packaging

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-<major_version>` （例如 `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 主版本以满足当前核心应用的需求？
+
+## 替代方案
+
+唯一的替代方案是维持现状，即由各应用自行捆绑运行时。如“动机”一节所述，此方案在资源利用、安全维护和生态一致性方面存在明显缺陷，不利于社区的长期发展。