哪些綁 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 要退回線上那個凍結的舊形狀，兩者對齊的目標相反。

對齊的載體是 image tag 跟 config，不是主機

Parity 不靠「把主機裝成跟 prod 一樣」達成——你的主機是 Arch 或 macOS 都無所謂。對齊的載體是 container 的 image tag 跟掛進去的 config：

• image tag 釘到 OS 世代：用 php:7.2-fpm-buster 而不是 php:7.2-fpm，把 PHP 版本連同底層 Debian 世代一起凍結（見 Image Tag Pinning）。
• 別為了省體積換 libc：prod 是 Debian（glibc）就別用 php:7.2-alpine（musl），DNS 與原生擴充行為會分岔（見 glibc 與 musl）。
• 服務設定抄 prod：MySQL 的 sql_mode、時區，PHP 的擴充清單與 php.ini，都從線上的權威來源抄、不憑印象填。SSH 進 prod 後用 mysql -N -e "SELECT @@sql_mode" 抓 sql_mode、php -m 列擴充、php -i（或 web 端存一支 <?php phpinfo();）看 php.ini 值；抄回來分別填進 db 的 my.cnf（sql_mode / 時區）、Dockerfile 的 docker-php-ext-install 清單（對照 php -m）、掛進去的 php.ini。

主機不變、只有這幾樣對齊——這是 parity 能在任何工作站上重現的原因。

要逐項比對的維度

跑起來後，用一個 probe 印出 runtime 的每個 parity 維度，跟 prod 逐行比對。每一行對應一個會影響行為的維度：

• PHP 主版 + patch 版
• 時區（PHP 與 MySQL 各一份，跨時區的 NOW() 是常見隱形 bug）
• 擴充清單（要相等、不是涵蓋；多裝的擴充讓本機能跑、prod 掛掉）
• MySQL 版本與 sql_mode（5.7 預設開 ONLY_FULL_GROUP_BY，舊 app 的 SELECT ... GROUP BY 未列全欄位會回 error 1055）

實測基線

dotfiles repo 的 runtimes/php72-mysql57/ 是一個跑得起來的 variant（PHP-FPM + MySQL 5.7 + nginx，docker-compose 組合）。docker compose up -d --build 起來後 curl http://localhost:8080/——probe 是一支 src/index.php、由 nginx 服務，逐行印出每個 parity 維度。arm64 macOS 實測（2026-07）輸出：

1PHP version : 7.2.34
2timezone    : Asia/Taipei
3MySQL ver   : 5.7.44
4sql_mode    : ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,...
5db timezone : +08:00

版本、時區、sql_mode 都跟 config 逐項對齊——這就是 parity 達成的樣子。

凍結舊環境的兩個稅

實跑會撞到兩個「照官方 docs 寫會 build 不起來、只有實機才知道」的問題，兩個都是凍結舊環境特有的：

• Debian buster 已 EOL：套件庫從主 mirror 移到 archive.debian.org，Dockerfile 裡不改 apt source 直接 apt-get update 就 404（exit 100）。要改指 archive 並關掉過期檢查。
• mysql:5.7 無 arm64 原生 image：在 Apple Silicon 主機上要 platform: linux/amd64 走模擬（機制見 QEMU binfmt 跨架構模擬）。這本身也是一種 parity——dev 是模擬 amd64、prod 是原生 amd64，架構對齊。

這兩個稅是 Prod Parity 原則 講的「對齊凍結環境要付的代價」的具體形態：凍結舊版意味著也繼承了它 EOL 與架構支援退場的後果。

什麼時候值得做到逐項

Parity 是有成本的紀律，不是每個專案都要做到逐項——值得與可放寬的完整判準見 Prod Parity 原則 的判讀訊號段。這篇的 PHP 7.2 場景屬「值得」那一類：有原生擴充、MySQL 嚴格模式、時區邏輯都在，本機不對齊就會在線上才發現行為不同。

下一步

runtime 對齊好之後，你會想在 container 裡用順手的 shell 跟 editor——但那不能直接塞進這個 image，否則 image 就不再等於 prod。怎麼把 ergonomics 帶進來又不污染 parity，見 dotfile 跨進 runtime container。

ergonomics 進可寫層，不進 image

最容易犯的錯是把 zsh、vim、個人 config 寫進 runtime 的 Dockerfile。一旦 ergonomics 進了 image，這個 image 就不再等於 prod——線上不會有你的 oh-my-zsh，parity 當場破功。判準很硬：

• runtime image 只裝 app 需要、prod 也有的套件（見 對齊 prod 的 runtime container）。
• ergonomics 裝進「已啟動的 container」：docker compose exec <service> bash 進去後才裝，或 docker compose cp 把檔案送進去（已啟動的 container 無法事後 mount，掛載只能在 compose / docker run 當下宣告）。它活在容器的可寫層、不進 image。

這條分層讓同一個 runtime image 既是「線上的忠實複製」又能「開發時很好用」，兩個需求不打架。

ergonomics 層自己也要可攜

runtime 的 base 是 Debian，但你的 dotfile 是照 Arch 或 macOS 寫的。ergonomics 安裝腳本要能在 Debian container 裡跑，靠的是 package manager detection——同一支腳本用 command -v apt-get / pacman / apk 分支，適配當下所在的環境。原理見 Package Manager 抽象層。

跟工作站的入口 detection 不同，container 內只裝少數幾個工具、不值得拆多檔，適合行內 detection：一支腳本內分支、共用同一份工具清單。dotfiles repo 的 runtimes/php72-mysql57/ergonomics/setup.sh 就是這個形態。

落地形態

裝套件那一步分 distro，config 部署完全共通：

• 裝工具：把 setup.sh 送進已啟動的 container 再跑——docker compose cp ergonomics/setup.sh php:/tmp/setup.sh && docker compose exec php bash /tmp/setup.sh，它偵測 package manager 裝 zsh/git/vim。
• 部署 config：dotfiles repo 送進去再 stow——docker compose cp ~/dotfiles php:/root/dotfiles && docker compose exec php bash -c 'cd /root/dotfiles && stow zsh git vim'。config 本身可攜、不分 distro（見 GNU Stow）。

這樣 config 只維護一份，跟工作站共用；container 內只多了「裝套件」那一層 distro 分支。

邊界

ergonomics 進可寫層的代價是「不持久」：container 重建就沒了，每次 docker exec 重來或寫成啟動時自動跑的腳本。這是刻意的取捨——為了保住 image 的 parity，換來 ergonomics 每次重建要重裝。想持久化 ergonomics 又不碰 runtime image，正解是走 devcontainer 那套（見 模組九：從個人到團隊），它把開發環境跟 runtime image 明確拆成兩個 image。

這個模組把 dotfile 的「環境可重現」思想延伸到兩個新對象：一是讓工作站 dotfile 跨到 client 常見的非 Arch 發行版，二是建一個跟線上逐項對齊的 runtime container。核心切分是三層，各自可重現、各自對齊不同目標。

三層切分

三層的哲學是同一套（環境 as code、可重現），差別只在對齊誰、綁哪個 package manager。把三者混進同一個 artifact 是常見錯誤：ergonomics 混進 runtime image，image 就不再等於 prod、parity 破功。

章節文章

這個模組的知識點

三篇實作文章都薄，只講目的與判讀；背後的設定原理拆成獨立術語卡：

• Prod Parity 原則：對齊凍結舊環境而非最新
• Image Tag Pinning：tag 要釘到 OS 世代才凍結得住
• glibc 與 musl：prod 是 Debian 就別用 alpine
• Package Manager 抽象層：綁 distro 的只有裝套件那一層
• 發行版打包粒度：同一指令跨發行版後果量級差多少
• apt 安裝的交易原子性：批次安裝為何全有或全無

實作 artifact

三層的實際檔案放在 dotfiles repo（不在教材裡）：工作站層是 repo 主體加 scripts/install-debian.sh，runtime 層是 runtimes/php72-mysql57/（Dockerfile + docker-compose），ergonomics 層是同目錄的 ergonomics/setup.sh。教材講判讀，repo 放可跑的設定。

跨分類引用

• → 模組九：從個人到團隊：devcontainer 是同一個「環境 as code」思想的團隊化形態
• → 模組八：同步、Bootstrap 與環境重建：跨 distro 安裝腳本是 bootstrap 的延伸
• → Container 術語卡：container 作為服務交付單位的服務設計視角

概念位置

底層 OS 世代為什麼影響行為，見 glibc 與 musl。實作見 對齊 prod 的 runtime container。

浮動 tag 與凍結 tag

同一個 image 的 tag 有不同精確度，愈短愈會漂：

1php:7.2-fpm          浮動 — 官方隨時 rebuild，底層 OS 從 stretch 換到 buster 你不會知道
2php:7.2-fpm-buster   釘住 PHP 主版 + OS 世代 — 這是 parity 的最低精確度
3php:7.2.34-fpm-buster 連 patch 版也釘死 — 完全凍結

php:7.2-fpm 這種浮動 tag 的問題是它「同名不同物」：官方每次安全更新都會用同一個 tag 重推，底層 Debian 世代、內建套件版本、glibc 版本都可能換掉。你本機三個月前 pull 的 7.2-fpm 跟 CI 現在 pull 的 7.2-fpm，可能是兩個不同 OS 世代的 image。

為什麼 OS 世代是最低精確度

Parity 要對齊的不只是 PHP 版本，是整個 runtime 的行為，而行為很大一部分由底層 OS 世代決定：glibc 版本、內建 CA 憑證、時區資料庫、系統套件版本。釘到 -buster 才把這層凍結；只釘 7.2 等於把 OS 世代交給官方的 rebuild 節奏決定。

判讀訊號

「本機能跑、CI 掛掉」或「上週還好、今天重 build 就壞」而 code 沒動時，第一個要查的就是有沒有用浮動 tag。凍結 tag 把「環境變了」這個變因從除錯空間裡消掉，讓你能專注在 code 差異。

邊界

釘死 tag 的代價是安全更新不會自動進來——凍結的 image 也凍結了已知漏洞。所以 pinning 搭配的是「明確的升級動作」：要更新時改 tag、重測、記錄（怎麼建升級版、又留住舊版並跑對照，見 image 版本管理與升級），而不是靠浮動 tag 偷偷幫你更新（那正是不可重現的來源）。取捨依 prod-parity 原則——對齊凍結環境本來就要付這個稅。

概念位置

這條規則跟 image tag pinning 同源：都是把 runtime 底層凍結到跟 prod 相同。判準見 prod-parity 原則。選 base image 的實作見 對齊 prod 的 runtime container 與 Dockerfile 設計。

誰用哪一套

主流商用發行版跟輕量容器發行版分屬兩邊：

1glibc  Debian, Ubuntu, RHEL/Rocky/Alma, CentOS  ← 商用 prod 幾乎都在這邊
2musl   Alpine Linux                              ← 容器界為了縮小體積常選這邊

Alpine 的賣點是 image 極小（base 約 5MB vs Debian 約 70MB），所以很多人反射性地選 php:7.2-alpine 來省空間。

為什麼 prod 是 glibc 就別用 musl

當 prod 跑在 Debian/Ubuntu（glibc）而你本機 image 用 Alpine（musl），你就在一個跟線上不同 libc 的環境開發，差異會在幾個地方咬人：

• DNS 解析行為不同：musl 不讀 /etc/nsswitch.conf、對 search domain 與並發查詢的處理跟 glibc 有別，容器內連內部服務時可能出現「本機解得到、線上解不到」或反過來。
• 原生擴充要重編：PHP/Python 的 C 擴充是對著某套 libc 編的；某些預編譯 wheel/extension 只提供 glibc 版，在 musl 上要自己編、甚至編不起來。
• locale 與時間格式：musl 的 locale 支援比 glibc 精簡，依賴特定 locale 的字串排序、日期格式可能不一致。

這些差異單獨看都小，但它們的共通點是「在你最不預期的地方，讓本機跟線上行為分岔」——正好抵消了本機模擬 prod 的目的。

判讀訊號

「本機容器跑得好好的、上線卻在 DNS 或某個原生擴充炸掉」是 libc 不一致的典型症狀。選 base image 時的判準很直接：prod 是什麼 libc，本機就用什麼。省那 60MB 換來的除錯成本遠高於節省。

邊界

musl 本身沒有問題——如果 prod 也跑 Alpine，那本機就該用 Alpine，parity 依然成立。重點不是「musl 比較差」，是「本機跟 prod 的 libc 要一致」。一個例外：如果 app 是純靜態連結的 binary（CGO_ENABLED=0 的 Go、Rust 靜態編譯），它不帶 libc 相依，上面 DNS / 原生擴充 / locale 三個咬人點全部消失——這時 base image 用 alpine 完全可行，即使 prod 的 base 不同（binary 自帶一切、不吃 image 的 libc）。

概念位置

這條原則是個人 dotfile「環境可重現性」思想往 runtime 層的延伸：模組零：Dotfile 心智模型 教的是工作站可重現，parity 教的是 runtime 可重現。要凍結到多細見 Image Tag Pinning。實作見 對齊 prod 的 runtime container。

對齊的是凍結環境，不是最新

接案 / 商用場景的 prod 通常是幾年前定版後就凍結的環境：PHP 7.2、MySQL 5.7、某個特定的 Debian 世代。這跟 rolling release 發行版（Arch）「永遠最新」的方向剛好相反。用你的 Arch 工作站直接當開發環境，等於在一個比線上新好幾代的環境寫 code，寫出來的成品可能用了線上沒有的語法、擴充或預設行為。

Parity 的意義就是把這個差距關掉：本機刻意退回線上那個舊形狀，讓「本機能跑」直接等於「線上能跑」。

要對齊哪些維度

Parity 不是只對齊語言版本號，是對齊會影響 runtime 行為的每一層：

• 語言版本：PHP/Python/Node 的主版與 patch 版
• 底層 OS 與 libc：Debian 世代、glibc vs musl（見 glibc 與 musl）
• 擴充/套件清單：php -m 逐項相等，不是涵蓋
• 服務版本：MySQL/Redis/nginx 的版本與關鍵設定（如 sql_mode、時區）
• image 精確度：用凍結 tag 把以上全部釘死（見 image tag pinning）

取得這些維度的權威來源是線上環境本身：php -m、SELECT @@sql_mode、phpinfo() 抄回來，而不是憑印象填。

判讀訊號：什麼時候值得逐項對齊

Parity 是有成本的紀律，不是每個專案都要做到逐項。值得的訊號：app 有原生擴充、依賴 DB 嚴格模式行為、有時區 / locale / charset collation 邏輯（MySQL 的 collation，以及 macOS 開發 ↔ Linux 部署的檔名大小寫敏感度差異，都常在這裡咬人）、或 client 明確凍結某版環境。可放寬的訊號：app 無原生擴充、不碰 DB 嚴格模式與時區 / collation（純直譯、行為跟 OS 世代解耦），或你完全掌控 prod（自己的 VPS，想升就升）——這時本機可以直接用較新的 stable，行為分岔風險低。

把這個判斷轉成對非技術決策者的話（接案時常要向業主 / PM 說明值不值得投入）：不對齊的代價是行為分岔只在線上才炸——本機測不出、上線才發現，變成緊急修加上客戶信任損耗；對齊的投入則是一次性建一個 parity runtime（通常幾小時到一天）。比較的是「一次性投入」對上「反覆的線上驚嚇與救火」，而不是純技術潔癖。

邊界

Parity 對齊的是「行為」，不是「連漏洞一起複製」。凍結舊環境意味著也繼承了它的已知漏洞與 EOL 稅（如 image tag pinning 提到的 base image mirror 退役）。Parity 讓你在本機重現線上問題，不代表線上該永遠停在舊版——它跟「該不該升級 prod」是兩個獨立決策。

概念位置

這個抽象讓 GNU Stow 管的 config 層完全可攜。實作見 工作站 dotfile 跨發行版落地 與 dotfile 跨進 runtime container。

綁 distro 的只有裝套件那一步

各發行版的差異集中在 package manager 的指令與套件名：

1Arch          pacman -S --needed --noconfirm <pkg>
2Debian/Ubuntu apt-get install -y --no-install-recommends <pkg>
3macOS         brew install <pkg>
4Alpine        apk add --no-cache <pkg>

除了這一步，其餘幾乎都可攜：.zshrc 的內容、stow 建 symlink 的方式、oh-my-zsh 的 git clone、config 檔本身——這些不管在哪個 distro 都一樣。所以跨 distro 的正解不是維護多份 dotfile，是維護一份 config + 一個依 package manager 分支的安裝層。

Detection 分支的兩種形態

抽象這一層有兩種常見寫法，差別在分支放哪：

• 入口 detection：安裝腳本開頭偵測 package manager，dispatch 到對應的 install-<platform>.sh，套件清單各平台一份（packages/arch-*.txt、packages/debian-*.txt）。適合工作站，因為各平台的套件集差異大。
• 行內 detection：一支腳本內用 command -v apt-get / pacman / apk 分支，共用同一份套件名。適合容器內的輕量 ergonomics 安裝——只裝少數幾個工具、不值得拆多檔。

判讀訊號：什麼進分支、什麼是共通層

判準是「這一項換 distro 會不會變」：會變的（套件名、安裝指令）進 detection 分支；不會變的（config 內容、symlink 邏輯、框架 clone）留共通層。一個常見的誤置是把套件名寫死在共通層，結果換 distro 就壞——正確做法是共通層只呼叫抽象後的安裝函式，具體套件名下沉到各平台清單。

套件名分歧的常見形態

「換 package manager」不只是換指令前綴，套件名本身在不同 distro 有好幾種分歧，各要不同處理：

• 同工具不同套件名：Arch 的 fd 在 Debian 叫 fd-find、github-cli 在 Debian 叫 gh。要靠各平台清單逐項對照，不能假設同名。
• binary 名被改：Debian 為了讓整個 archive 的 /usr/bin 名字全域唯一，會在上游 binary 名跟現有套件撞名時改名——fd-find 裝出來的 binary 是 fdfind、bat 是 batcat。所以「套件裝好了」不等於「指令叫得動」，.zshrc 的 alias 要按平台補（Debian 上 alias fd=fdfind）。
• 名字撞到別的工具：apt install delta 裝到的是一個 heuristic minimizer、不是 .gitconfig 指的那個 diff pager（那個叫 git-delta、且 bookworm 沒打包）。同名不同物，照抄會裝錯東西。
• 套件被拆分或合併：同一個上游工具在 Debian 常被拆成 foo + foo-dev + foo-common（照抄單一名字會漏裝 -dev、編不起來），或反過來多個工具併進一個 meta-package（如 build-essential）。安裝顆粒度跟 Arch 不對齊，要看該 distro 怎麼切。

除了名字，同名套件的版本也常分歧：Debian stable 凍結的版本往往比 Arch 舊一個世代，名字一樣、行為卻不同——這不是名字問題，但一樣影響對齊，見 發行版打包粒度。

邊界

當某工具在目標 distro 根本沒打包時，抽象層也擋不住——退回手動安裝或換等價工具。哪些工具在保守發行版容易缺席，見 發行版打包粒度；為什麼清單裡一個爛名字會拖垮整批安裝，見 apt 安裝的交易原子性。

概念位置

這條跟 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、後來被移出」的漂移見 發行版打包粒度）。想繞過「一個失敗全滅」可以逐包安裝（迴圈裡一個一個裝、失敗的跳過），但那會失去交易的一致性保證、也讓「哪些沒裝成功」變得難追。多數情況正解是把清單修對，而不是放棄原子性。