哪些綁 distro、哪些共用

拿到一份 dotfile 要跨 distro 時，先把內容分成兩堆，判準是「換 distro 會不會變」：

• 會變、要下沉到平台層：套件安裝指令（pacman vs apt-get）、套件清單、以及套件名分歧的工具。
• 不會變、留共通層：.zshrc 內容、stow 建 symlink 的邏輯、oh-my-zsh 的 git clone、所有 config 檔本身。

判斷錯的代價是把套件名寫死在共通層——換 distro 就壞。正確形態是共通層只呼叫「裝套件」這個抽象動作，具體套件名交給各平台清單。

落地：入口 detection + 平台清單

工作站的套件集在不同 distro 差異大，適合用入口 detection：安裝腳本開頭偵測 package manager，dispatch 到對應的平台腳本。dotfiles repo 的形態是 install.sh 判斷 OS 後委派給 install-arch.sh / install-macos.sh / install-debian.sh，套件清單各一份（packages/arch-*.txt、packages/debian-*.txt），共通的環境組裝（stow、框架 clone）留在 install.sh。

跨到 Debian 只需要補一支 install-debian.sh 跟對應清單，共通層一行都不用動——這正是抽象層有效的證據。

套件名分歧：裝好不等於叫得動

同一個工具在不同 distro 的名字有好幾種分歧（有哪些形態、為什麼，見 Package Manager 抽象層）。落地時按形態各自處理：

• 套件名不同（fd → fd-find、github-cli → gh）：靠各平台清單逐項對照，不假設同名。
• binary 被改名（fd-find 的 binary 是 fdfind、bat 是 batcat）：.zshrc 按平台補 alias（alias fd=fdfind）——「套件裝好了」不等於「指令叫得動」。
• 名字撞到別的工具（apt install delta 裝到的不是 .gitconfig 要的 git-delta）：別照抄，確認同名同物。

ripgrep 兩邊同名（binary 都是 rg）不用處理，fd / bat 就要按上面吸收。

實作會遇到的狀況與排除

跨到 Debian 實跑時，除了名字分歧，還有幾個操作面的狀況會擋住 bootstrap。先知道怎麼排除：

• 全新映像連 sudo/git 都沒有。乾淨的 Debian 映像預裝極簡，install.sh 要用到的 sudo、git 本身都缺。排除：bootstrap 第一步先 apt-get install -y sudo git，才有辦法 clone repo、跑後續。這是最小映像的預期形態，不是壞掉。

• 清單裡一個沒打包的名字讓整批全滅。apt-get install 是一筆全有或全無的交易，清單塞一個 Debian 沒有的名字（實測 broot、zellij 在 bookworm 沒打包），apt 直接中止，同批存在的工具也一個都沒裝。排除：清單逐項對齊該 distro 實際有的套件，動手前用 apt-get install -s <pkg> 逐一 dry-run 篩掉解不開的。原理見 apt 安裝的交易原子性。

• 某些工具 Debian 根本沒打包。broot、zellij、git-delta、lazygit、yazi 在 bookworm 預設 repo 都不存在（Arch 都有）。排除：把它們移出 apt 清單，改從 GitHub releases 裝——抓對應架構的預編譯檔（curl -L -O <release-url>）、解壓、chmod +x、mv 到 ~/.local/bin（確認它在 PATH）；若走 cargo install，cargo 本身要先用 rustup 裝（裸 Debian 沒有）。原理見 發行版打包粒度。

• 裝個 node 拉進幾百個系統套件。apt install nodejs npm 在 Debian 會連帶 300 多個 node-* 套件（實測 bookworm 一次裝進 402 個新套件、其中 336 個是 node-*）。要避免的是拿系統套件管理器裝語言執行環境。排除：node / python / ruby 這類語言生態走 version manager（fnm / pyenv）在家目錄管，別放進 apt 清單。原理見 發行版打包粒度。

邊界與下一步

桌面層（Hyprland 的 rice，即桌面視覺客製化）的跨 distro 成本遠高於 CLI 層：Hyprland 在 Debian 要較新版才有打包，套件名與可用性都要重驗，所以工作站跨 distro 通常只做到 terminal 層，桌面留在實測過的 Arch。

工作站跨好之後，開發還缺一個對齊 client 線上的 runtime——那是下一篇 對齊 prod 的 runtime container。工作站是你的機器、可以最新；runtime 要退回線上那個凍結的舊形狀，兩者對齊的目標相反。

概念位置

這條跟 Package Manager 抽象層 互補：抽象層講「同一件事換 backend 怎麼寫」，這張講「同一個指令換 backend 後果量級差多少」。一個爛名字為何拖垮整批安裝，見 apt 安裝的交易原子性。實作上怎麼判斷該不該進 apt 清單，見 工作站 dotfile 跨發行版落地。

兩種粒度

以 nodejs + npm 為例，同樣一個安裝動作在兩種發行版的展開差一個量級（Debian bookworm 實測）：

1Debian   apt install nodejs npm   → 連帶 402 個新套件（其中 336 個 node-*，eslint、node-glob…每個 JS lib 一個 .deb）
2Arch     pacman -S npm            → 只拉少數幾個；JS library 交給 npm 在 node_modules 管

Debian 的哲學是「所有東西都是系統套件」，所以它把 nodejs / npm 工具鏈本身的相依也拆成上百個 node-* deb，一次 apt install npm 就全灌進系統。要分清楚：這些 node-* 是 Debian 為了打包 node 工具鏈而拉進的系統層相依，跟你專案 npm install 進 node_modules 的依賴無關——後者不論哪個 distro 都走 npm、從不碰 apt。所以「402 套件」講的是系統工具鏈膨脹，不是應用依賴。Arch 不把這層 library 納入系統套件，同一個 npm 只在系統層多幾個檔案。

為什麼有的工具乾脆沒打包

粒度策略也決定「哪些工具進得了官方 repo」。移動快速的新工具（多為 Rust 寫的 CLI）在保守、定版凍結的發行版常常還沒被打包：broot、zellij、git-delta、lazygit、yazi 在 Debian bookworm 的預設 repo 都不存在，但在 Arch 都有。發行版愈保守（stable 凍結愈久），這類缺口愈多。

repo 成員資格會隨時間漂移

「沒打包」不只是「保守發行版從沒收」的靜態狀態，也可能是「曾經收、後來被移出」的時間變化。官方 repo 會把不再維護的套件汰除：autojump（目錄跳轉工具）一度在 Arch 官方 repo，後來被移到 AUR，現在 pacman -S autojump 回 target not found——同一個發行版、同一個套件名，只是時間軸上的成員資格變了（維護版替代是 zoxide，仍在官方 repo）。這讓一份釘死的套件清單即使不換發行版也會腐化：清單寫的當下該套件在官方 repo、幾年後被移出，清單就在新機器上裝不起來。判讀是：target not found 且你確定名字沒打錯、以前明明裝得起來，就往「它被移出官方 repo 了」查（多半移到 AUR，或改由上游自行發佈 binary）。若整批一次裝，一個被移出的名字還會拖垮整批（見 apt 安裝的交易原子性）。

判讀訊號

安裝一個工具卻拉進幾百個套件時，先問「這些是不是某個語言生態的 library」。是的話，通常代表這東西不該走系統套件管理器——語言生態的執行環境（node、python、ruby）交給 version manager（fnm / pyenv / rbenv）在家目錄管更乾淨：可切版本、不污染系統、不被發行版凍在舊版。系統套件管理器留給「系統層工具」本身。

反過來，某工具 apt install 直接 unable to locate 時，多半是它還沒進這個發行版的 repo，不是名字打錯——退回 GitHub releases 的預編譯 binary 或 cargo install。

邊界

粒度細不是缺點：Debian 把 library 拆成系統套件，換來的是每個 library 都能收到發行版的安全更新與依賴一致性保證，這對伺服器場景有價值。問題只出在「拿它裝語言生態的開發依賴」——那是 version manager 的場域。判斷依用途，不是依發行版好壞。

解析與安裝是兩階段

apt 把「算出要裝什麼」跟「實際裝」分成先後兩步：

1階段一 解析：把 a b c + 全部依賴解成一份計畫；任一個解不到 → 整筆 abort，什麼都沒動
2階段二 安裝：計畫完整才下載、解包、設定

這是刻意的設計。系統套件之間有依賴關係，半裝的狀態（裝了 a、b 因為 c 失敗而中途停）會留下依賴不完整的系統，比「全部沒裝」更難收拾。全有或全無讓系統永遠停在一致的狀態。

概念位置

這解釋了為什麼跨發行版的套件清單要 curate、不能照抄，跟 Package Manager 抽象層 的「套件名分歧要逐項吸收」是同一件事的兩面。哪些工具在保守發行版沒打包，見 發行版打包粒度。清單 curate 的實作見 工作站 dotfile 跨發行版落地。

一個爛名字全滅

實務上最容易撞到的後果：批次清單裡塞了一個該發行版沒有的套件名，整批就全部不裝。實測在 Debian bookworm 跑一份含 broot、zellij（兩者 bookworm 沒打包）的清單，apt 回 Unable to locate package broot / zellij 後直接中止，同批的 autojump、gh、tig 明明存在也一個都沒裝。

症狀是「我明明列了十個工具、跑完一個都沒有」，根因不是每個都失敗，是其中一兩個爛名字讓整筆交易 abort。

判讀訊號

批次安裝清單必須逐項對齊該發行版實際有的套件，不能從別的發行版直接抄名字過來。動手前用 dry-run 先驗：

1apt-get install -s a b c    # -s 模擬，只解析不安裝，先看有沒有 Unable to locate

一個一個 dry-run 能精準指出哪個名字解不開，再把它移出批次清單、或換成該發行版的正確名字。

邊界

pacman 的批次安裝有類似的原子性——實測 pacman -S 一份含 autojump 的清單，因 autojump 已從 Arch 官方 repo 移到 AUR、回 target not found，整批就 abort，同清單裡本來裝得起來的 zoxide、ripgrep、fd 一個都沒裝（這種「曾在官方 repo、後來被移出」的漂移見 發行版打包粒度）。想繞過「一個失敗全滅」可以逐包安裝（迴圈裡一個一個裝、失敗的跳過），但那會失去交易的一致性保證、也讓「哪些沒裝成功」變得難追。多數情況正解是把清單修對，而不是放棄原子性。