我多次遇到用戶抱怨 LTS 和穩(wěn)定版的應(yīng)用軟件包有問題，但又聲稱開發(fā)版從來沒有發(fā)生過這種事情。然而，以我在軟件包技術(shù)方面的經(jīng)驗(yàn)和知識(shí)，我不能不強(qiáng)調(diào)，這是不對(duì)的。

發(fā)行模式不是問題的根源所在，根本的問題是傳統(tǒng)的軟件包格式不適合現(xiàn)代的圖形應(yīng)用，不管是什么發(fā)行版。那么像 Nix 和 Flatpak 這樣的格式是如何解決這些基本問題的？有趣的是，大多數(shù)服務(wù)器確實(shí)利用了容器化（即 Docker），因?yàn)樗岣吡丝芍貜?fù)性并增強(qiáng)了可維護(hù)性。我們可以從中得到啟發(fā)，采用一個(gè)適用于 Linux 桌面的類似標(biāo)準(zhǔn)。

免責(zé)聲明

1. “傳統(tǒng)軟件包”是指使用包管理器發(fā)布的圖形應(yīng)用程序，而不使用容器，如??apt???、??dnf???、??pacman?? 等。
2. “發(fā)行模式”是指發(fā)行過程，如長(zhǎng)期支持版（LTS）、穩(wěn)定版和開發(fā)版等。
3. “類似的應(yīng)用程序”是指兩個(gè)在技術(shù)上真正相似的應(yīng)用程序，如??Visual Studio Code??? 和??Code - OSS??。
4. 在這些例子中，我將使用 Arch Linux 作為參考。然而，這些行為與那些大量采用傳統(tǒng)軟件包格式的發(fā)行版是一致的。
5. Nix 不使用容器，它也不是一種容器格式。但為了簡(jiǎn)單起見，我暫時(shí)把它稱為一種容器格式。

根本問題?

大多數(shù)（或許不是全部）大量采用傳統(tǒng)軟件包格式的發(fā)行版都有這個(gè)共同的問題：它們都沒有利用容器或其他方便的方法來分離依賴關(guān)系。用通俗的話說，容器是一個(gè)盒子，我們可以把東西放在里面，在不影響主系統(tǒng)（主機(jī)）的情況下單獨(dú)使用它們。

容器通常不會(huì)影響“盒子”外的任何東西。并且它們是可移植的，因?yàn)樗鼈兛梢园惭b在其他發(fā)行版上，同時(shí)提供一致的體驗(yàn)。利用容器的包管理器會(huì)將每個(gè)軟件包安裝在不同的容器中，這提供了一個(gè)額外的安全層。這給了開發(fā)者更多的控制權(quán)和靈活性，他們可以決定在軟件包內(nèi)捆綁什么。

傳統(tǒng)的軟件包格式產(chǎn)生了一些問題，比如依賴性和包的沖突，這些問題通常需要解決，而不同的發(fā)行版有不同的解決辦法。

依賴性和軟件包的沖突

如果我們?cè)噲D安裝 ??Visual Studio Code???（??visual-studio-code-bin???），而 ??Code - OSS???（??code??） 已經(jīng)安裝在 Arch Linux 上，我們會(huì)遇到這個(gè)問題：

$ paru -S visual-studio-code-bin
    [...]
    :: Conflicts found:
        visual-studio-code-bin: code  
    :: Conflicting packages will have to be confirmed manually
    Aur (1)                     Old Version  New Version  Make Only
    aur/visual-studio-code-bin               1.70.1-1     No

這就是所謂的軟件包沖突，即兩個(gè)或多個(gè)軟件包不能共存。在這種情況下，我們不能同時(shí)安裝 Visual Studio Code 和 Code - OSS。

當(dāng)兩個(gè)應(yīng)用程序或軟件包提供相同的文件，具有相同的名稱，并被放置在同一目錄下，那么它們實(shí)際上是不能共存的，因?yàn)檫@些文件會(huì)發(fā)生沖突。在這個(gè)例子中，Visual Studio Code 和 Code - OSS 都提供了一個(gè)名為 ??code??? 的文件，它們都被放在 ??/usr/bin??? 中。Visual Studio Code 提供的 ??code??? 文件用于啟動(dòng) Visual Studio Code，而 Code - OSS 的 ??code?? 文件則用于啟動(dòng) Code - OSS。 雖然這個(gè)例子只展示了 Visual Studio Code 和 Code - OSS，但這種情況經(jīng)常發(fā)生在不同的應(yīng)用程序、庫和其他軟件中。

無法選擇依賴項(xiàng)?

傳統(tǒng)軟件包格式的最大問題之一是，打包者不能選擇依賴項(xiàng)。

例如，如果一個(gè)應(yīng)用程序最近更新，需要依賴版本 1 的程序 A，但發(fā)行版只提供了版本 0.9 的程序 A，那么對(duì)于升級(jí)該應(yīng)用程序來說就不太理想，因?yàn)榘l(fā)行版無法滿足要求。這意味著打包者將不得不暫緩打包，直到該發(fā)行版發(fā)布新的依賴項(xiàng)，或者采用變通的方法。

同樣，如果一個(gè)應(yīng)用程序需要依賴 0.8.1 版本的程序 A，但發(fā)行版卻只提供了 0.9 版本的程序 A，那么這個(gè)應(yīng)用程序就會(huì)表現(xiàn)失常，甚至完全不能運(yùn)行。

帶補(bǔ)丁的庫和編譯配置

為了擴(kuò)展，一些應(yīng)用程序需要帶補(bǔ)丁的庫或額外的編譯配置才能正常運(yùn)行。例如，OBS Studio 需要一個(gè) ??打了補(bǔ)丁的 FFmpeg?? 來與 OBS Studio 更好地整合。

在傳統(tǒng)的軟件包格式下，一次只能安裝一個(gè)依賴項(xiàng)的變體。如果發(fā)行版提供的是未打過補(bǔ)丁的 FFmpeg，那么就沒有辦法安裝打過補(bǔ)丁的 FFmpeg，除非打包者能解決這個(gè)問題。如果安裝了打過補(bǔ)丁的 FFmpeg，但另一個(gè)程序高度依賴未打過補(bǔ)丁的 FFmpeg、打過其他補(bǔ)丁的 FFmpeg、內(nèi)置或刪除了其他功能的 FFmpeg，那么其他程序就會(huì)出現(xiàn) bug。

現(xiàn)代應(yīng)用程序本質(zhì)上是脆弱的。依賴關(guān)系樹中的一個(gè)小錯(cuò)誤或不一致，就會(huì)導(dǎo)致應(yīng)用程序的 bug，使用戶體驗(yàn)惡化，甚至?xí)屓擞X得是應(yīng)用程序的問題，而不是軟件包本身的問題，這就會(huì)妨礙應(yīng)用程序的聲譽(yù)。

變通方法

讓我們看看目前開發(fā)者用來打包應(yīng)用程序的變通方法：

1. 第一種解決方法是在不同的目錄中安裝依賴庫。例如，Electron 是一個(gè)巨大的框架，開發(fā)者用它來構(gòu)建應(yīng)用程序，然后將它們捆綁起來。然而，基于 Electron 的應(yīng)用程序是不同的，因?yàn)樗鼈兪墙⒃诓煌姹镜? Electron 之上的。Discord 捆綁了 Electron 13，而 Element 捆綁了 Electron 19。對(duì)于 Arch Linux 上的 Electron 打包，某些目錄需要安裝在??/opt/APPLICATION_NAME??? 中，所以這些 Electron 版本??不會(huì)相互沖突??。
2. 第二種解決方法是篡改應(yīng)用程序。例如，給應(yīng)用程序打上補(bǔ)丁，使其在沒有某些依賴庫或功能的情況下編譯，這可以使應(yīng)用程序成功編譯，但不能保證該應(yīng)用程序能夠啟動(dòng)或按預(yù)期工作。
3. 第三種解決方法是在編譯應(yīng)用程序時(shí)禁用許多編譯選項(xiàng)，這也可能禁用一些功能。例如，在 Arch Linux 上，OBS Studio 在編譯時(shí)禁用了許多基本功能，這??導(dǎo)致了不合格的體驗(yàn)??。

這些解決方法因人而異，有些會(huì)限制應(yīng)用程序的功能，有些會(huì)引入穩(wěn)定性問題等等。

不一致的體驗(yàn)

雖然這些技術(shù)限制在整個(gè)傳統(tǒng)軟件包格式中是一致的，但用戶體驗(yàn)往往不是這樣。由于軟件包的發(fā)布方式，發(fā)行模式與傳統(tǒng)軟件包格式相結(jié)合會(huì)影響用戶體驗(yàn)。

一些發(fā)行版，如 Arch Linux，接近于開發(fā)版，因此有最新版本的軟件包。然而 Debian 和 Ubuntu LTS 是 LTS 長(zhǎng)期支持版，所以它們的很多軟件包都落后幾個(gè)版本。同時(shí)，F(xiàn)edora Linux 和 Ubuntu 穩(wěn)定版處于 Debian / Ubuntu LTS 和 Arch Linux 之間。

一些軟件包格式喜歡盡可能少地給軟件包打補(bǔ)丁，以保持它們最接近原版；而另一些格式打補(bǔ)丁是為了增加更多的功能，使用舊庫或進(jìn)行其他類型的更改，以改善用戶體驗(yàn)。一些格式喜歡使軟件更加輕量化；而另一些格式更喜歡盡可能地添加更多內(nèi)置功能。軟件包有各種各樣的習(xí)慣和偏好。

正如我們所看到的，一個(gè)應(yīng)用程序在不同的發(fā)行版中的構(gòu)建方式非常不同。此外，不同的發(fā)行版的依賴關(guān)系也是不同的。傳統(tǒng)軟件包格式的許多技術(shù)限制需要根據(jù)發(fā)行模式和打包策略采取不同的解決方法。這些微小的變化往往給用戶帶來不完整的、不合格的體驗(yàn)和錯(cuò)誤的印象。一些應(yīng)用程序可能在某些發(fā)行版上運(yùn)行得更好，但在其他發(fā)行版上運(yùn)行得很差，而其他一些應(yīng)用程序則運(yùn)行得更好。即使一個(gè)應(yīng)用程序在每個(gè)發(fā)行版上的構(gòu)建方式不同，但其名稱和品牌卻保持原樣，給用戶留下錯(cuò)誤的印象。

解決方案?

如上所述，解決這些問題的方法是使用容器。

容器被設(shè)計(jì)用來分離系統(tǒng)的幾個(gè)方面。通過使用容器，打包者可以挑選依賴項(xiàng)而不受主機(jī)上的庫限制。因此，打包者可以發(fā)布最新的、功能完整的軟件包，同時(shí)保持發(fā)行的穩(wěn)定性。

這一點(diǎn)非常重要，因?yàn)檫@些容器格式可以將應(yīng)用程序和發(fā)行版發(fā)揮出最大的作用，而不會(huì)對(duì)系統(tǒng)造成破壞性的影響。

Nix 和 Flatpak

??Nix??? 是一個(gè)跨平臺(tái)的包管理器，可以在類 Unix 操作系統(tǒng)中運(yùn)行，如 Linux 發(fā)行版、BSD 和 macOS。Nix 有幾個(gè) ??通道??（分支）供用戶使用。

另一方面，??Flatpak?? 是一個(gè)用于 Linux 桌面的通用軟件包格式，它也利用容器，但另外還有沙盒來隔離它們。它旨在以后可以供普通人使用，并被設(shè)計(jì)為與軟件商店（如 GNOME “軟件Software” 和 KDE “發(fā)現(xiàn)Discover）集成。換句話說，F(xiàn)latpak 更像是發(fā)行版的一個(gè)擴(kuò)展，而不是一個(gè)軟件包格式的替代品，因?yàn)樗脑O(shè)計(jì)初衷不是為了取代系統(tǒng)包管理器。

如果使用 NixOS 等發(fā)行版，Nix 也可以作為一種擴(kuò)展或單獨(dú)使用。

類似的應(yīng)用

Nix 和 Flatpak 解決了傳統(tǒng)軟件包格式的許多基本問題。由于應(yīng)用程序的分離，這些格式可以安裝類似的應(yīng)用程序，如 Visual Studio Code 和 Code - OSS，而不會(huì)沖突。

多個(gè)版本

Nix 和 Flatpak 可以安裝同一個(gè)應(yīng)用程序的多個(gè)版本。使用 Nix，我可以從 ??nixpkgs-stable???（LTS）安裝應(yīng)用程序，同時(shí)也可以從 ??nixpkgs-unstable??（開發(fā)版）安裝同一個(gè)應(yīng)用程序。

同樣地，使用 Flatpak，我可以同時(shí)從 ??stable??? 和 ??beta?? 分支安裝應(yīng)用程序。我可以從更多的途徑和分支繼續(xù)安裝同一個(gè)應(yīng)用程序，而不會(huì)遇到?jīng)_突。

挑剔的依賴項(xiàng)

此外，打包者可以將應(yīng)用程序與不同變體的庫捆綁在一起，從而有機(jī)會(huì)啟用更多的構(gòu)建選項(xiàng)，并使用打過補(bǔ)丁或特定版本的庫，從而為用戶提供完整的體驗(yàn)。

這意味著打包者可以將打了補(bǔ)丁的 FFmpeg 與 OBS Studio 捆綁在一起，只為了用在 OBS Studio

中。如果我在主機(jī)上安裝了普通的 FFmpeg，那么 OBS Studio 的補(bǔ)丁 FFmpeg 就不會(huì)與主機(jī)的 FFmpeg 發(fā)生干擾或沖突。

各個(gè)發(fā)行版的環(huán)境都是一致的

如上所述，各發(fā)行版使用不同的補(bǔ)丁、構(gòu)建選項(xiàng)和環(huán)境構(gòu)建應(yīng)用程序。這導(dǎo)致了應(yīng)用程序的碎片化，每個(gè)應(yīng)用程序的構(gòu)建方式和工作方式往往不盡相同。由于

Nix 和 Flatpak 是為跨發(fā)行版運(yùn)行而設(shè)計(jì)的，它們?cè)诿總€(gè)發(fā)行版中為應(yīng)用程序提供一致的環(huán)境，前提是發(fā)行版提供了 Nix 或

Flatpak 的支持版本。

缺點(diǎn)

就像所有事物一樣，Nix 和 Flatpak 不是完美的。由于最近在 Linux 桌面上容器技術(shù)得到了推崇，它們可能為許多應(yīng)用程序提供了不尋常的環(huán)境。

Flatpak 不僅包含了應(yīng)用程序，還對(duì)它們進(jìn)行沙盒處理。Flatpak 的開發(fā)者已經(jīng)實(shí)施了一個(gè)短期的變通方案，“在沙盒上打洞”，即所謂的靜態(tài)權(quán)限。他們正在開發(fā)適當(dāng)?shù)拈L(zhǎng)期解決方案，稱為 ??XDG 門戶??，以解決有關(guān)沙盒的許多問題，并使其像 Android 的安全模型一樣。

唯一的短期問題是，工具包、框架和應(yīng)用程序必須采用這些標(biāo)準(zhǔn)。GTK 和 Qt 這樣的工具包集成了其中一些門戶portal，但它們也需要時(shí)間來集成其他的門戶。同時(shí)，許多其他的工具箱還沒有真正集成任何門戶。

工具包、框架和應(yīng)用程序采用這些新標(biāo)準(zhǔn)是一個(gè)時(shí)間問題，因?yàn)樵?XDG 門戶之前沒有任何適當(dāng)?shù)臉?biāo)準(zhǔn)。應(yīng)用程序可以直接訪問文件系統(tǒng)和 API，所以靜態(tài)權(quán)限保持這種 “標(biāo)準(zhǔn)”。

結(jié)論

傳統(tǒng)軟件包格式的根本問題是它沒有利用容器。許多圖形化的應(yīng)用程序本質(zhì)上是復(fù)雜的，需要非常具體的依賴關(guān)系才能按預(yù)期運(yùn)行。許多發(fā)行版通過使用變通的方法在不同的環(huán)境中構(gòu)建同一個(gè)應(yīng)用程序，例如給應(yīng)用程序打補(bǔ)丁或禁用某些構(gòu)建選項(xiàng)。這導(dǎo)致了一個(gè)應(yīng)用程序的不同變體、不一致的行為和不合格的用戶體驗(yàn)。

當(dāng)然，發(fā)行版的維護(hù)者不可能在幾天內(nèi)現(xiàn)實(shí)地重寫他們的包管理器并使用容器。這些重寫會(huì)破壞許多腳本、功能等，而且還需要很長(zhǎng)時(shí)間才能投入生產(chǎn)環(huán)境。

我個(gè)人的建議是使用和推廣 Flatpak，因?yàn)樗皇菫榱藬U(kuò)展現(xiàn)有的發(fā)行版，而不是取代它。打包者不必?fù)?dān)心打包應(yīng)用程序，以及訴諸變通的問題，因?yàn)?Flatpak 已經(jīng)在處理這些問題了。

作者 Hari Rana ??最初發(fā)表于此博客??。

Hari 是 Fedora 雜志的 Fedora 編輯委員會(huì)的成員。他也是 Fedoea 質(zhì)量保證（QA）的一員。Hari 希望通過推廣各種技術(shù)和幫助需要幫助的人，為 Linux 桌面的采用作出貢獻(xiàn)。

本文所表達(dá)的觀點(diǎn)和意見是作者本人的，并不代表我們的觀點(diǎn)。