From 0d418d037e55353d385e639b331513e2226345c5 Mon Sep 17 00:00:00 2001 From: Ryan Yin Date: Fri, 22 Nov 2024 12:58:40 +0800 Subject: [PATCH] docs: nixpkgs git workflow --- linux/nixos/nixpkgs-workflow.md | 32 +++++++++++++++++++++++--------- 1 file changed, 23 insertions(+), 9 deletions(-) diff --git a/linux/nixos/nixpkgs-workflow.md b/linux/nixos/nixpkgs-workflow.md index acf0dc96..39adfe16 100644 --- a/linux/nixos/nixpkgs-workflow.md +++ b/linux/nixos/nixpkgs-workflow.md @@ -49,29 +49,43 @@ arch 的 xxx-testing 与正式仓库之间. 而 arch 应该总是能确保所有 core 与 extra 包都能正常构建(问题都应该在 xxx-testing 仓库解决), 因此其稳 定性会比 nixpkgs 的 unstable 分支更高. - -为了兼顾稳定性与版本够新, 一般推荐默认使用 stable 分支, 对需要新版本的软件, 再单独从 unstable 分支引入. +为了兼顾稳定性与版本够新, 一般推荐默认使用 stable 分支, 对需要新版本的软件, 再单独从 unstable 分支引 +入. 这样做的缺点是, 相比 arch linux, 系统的各软件版本可能会比较滞后. - - ## 吐槽 - 经常有人提 PR 把 unstable 搞坏, 而且还不愿意修复? nixpkgs 现在这个局面就是它的架构跟工作流设计导致的，跟某个个人没有关系。 -nixpkgs 感觉相当于 arch + AUR，导致很多 maintainer 对一些比较老的包不感冒，毕竟都不知道还有没有人在用。 +nixpkgs 感觉相当于 arch + AUR，导致很多 maintainer 对一些比较老的包不感冒，毕竟都不知道还有没有人在 +用。 -打个比较, python maintainer 就只想维护 python 自身，并希望被破坏掉的其他依赖，由相关的 maintainer 自己修。 +打个比较, python maintainer 就只想维护 python 自身，并希望被破坏掉的其他依赖，由相关的 maintainer 自 +己修。 如果是在 arch 上, 那至少 python 的更新在相关的其他 core/extra 包都能正常构建后才会被合并到正式仓库。 但在 NixOS 上, 它就直接被自动 merge 到 unstable 分支了, 导致稳定性欠佳. -之前也有人提过为什么 nixpkgs 不像 arch 那样多加个 extra 维护级别跟 testing 分支呢? -不这么干的主要原因可能是: 人手与资源都不够, 多加一个分支就意味着多维护一个分支、多一堆 CI 构建、多一分 s3 cache 存储. +之前也有人提过为什么 nixpkgs 不像 arch 那样多加个 extra 维护级别跟 testing 分支呢? 不这么干的主要原 +因可能是: 人手与资源都不够, 多加一个分支就意味着多维护一个分支、多一堆 CI 构建、多一分 s3 cache 存 +储. -另外当前的 monorepo + git 工作流可能会成为瓶颈, 拖慢了一个包的更新 PR 从合并到 master 到进入 unstable 的时间. +另外当前的 monorepo + git 工作流可能会成为瓶颈, 拖慢了一个包的更新 PR 从合并到 master 到进入 +unstable 的时间. > 另一个可能性是, NixOS 缺少肥猫这样的超级打包人 ( +## 有人在尝试解决这个问题吗? + +确实有! 下面我会列出一些我知道的尝试. + +### 1. Ekapkgs poly-repo Nixpkgs fork "Nixpkgs for mortals" + +https://github.com/ekala-project/ekapkgs-roadmap + +Ekspkgs 是一个将 Nixpkgs 这个 monorepo 拆分成多个 repo 分别维护的尝试, 以尽可能降低维护者的负担, 从 +而 +1. 避免出现常常有一堆包构建失败的情况. +1. ...