[[324843]]

編者按：本文介紹了一些另類的暴力破解 RPM 和 DEB 軟件包依賴關(guān)系的方法，對陷入依賴陷阱而不可自拔的人來說，有時候這也是一種絕地求生之路。至于說這樣做是否合適，那就是一件見仁見智的事情了，不過這種硬剛的不罷休態(tài)度值得贊賞。此外，本文中一些觀點(diǎn)僅代表作者的認(rèn)識，未必一定正確，大家爭鳴即可。

本文的轉(zhuǎn)載得到了作者授權(quán)。

最近正好在研究 dpkg 和 rpm，對 Linux 依賴有了更深的認(rèn)識。

在網(wǎng)上看了很多，所有 Docker、虛擬機(jī)、編譯安裝、以及各種另辟蹊徑的答案，都是面向日常繁重的業(yè)務(wù)沒時間折騰而不得已做出的妥協(xié)和讓步。

而我們面向技術(shù)的，“從來都喜歡正面硬剛！”

硬剛 Linux 軟件安裝依賴問題的辦法有很多，我給他分為兩大類！

“一類合法，另一類暴力。”

先說合法的解決方案

也是所有人都知道的解決方案：

sudo apt-get install xxxxx

一般情況下，它會連帶軟件的依賴一起安裝。如果這個過程中依賴安裝失敗，就執(zhí)行：

sudo apt-get -f install

一次不行兩次，只要源里有，只要能保證依賴關(guān)系是順暢的，再多的依賴多執(zhí)行幾次都能裝完。

如果有依賴源里找不到。這個坑就踩不過去了，解決辦法是：找到缺失的庫的安裝包手動下載下來。然后通過 sudo dpkg -i xxxx.deb 安裝。

需要手動下載安裝包的尋找主要有兩個途徑：

1. 百度找，直接搜包名 + 版本號并帶上關(guān)鍵字 deb
2. 通過源。

百度直接找?guī)炀筒欢嗾f了，額外說一下通過源怎么找。

你在網(wǎng)上搜 ubuntu 國內(nèi)源。會找到很多類似這樣的寫法：

deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ xenial main restricted universe multiverse

這其實(shí)即是給apt-get工具配置的源地址，也是個實(shí)際的網(wǎng)址，你可以直接從瀏覽器里訪問到，比如上面這個：

https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ xenial main restricted universe multiverse

它其實(shí)代表的是：https://mirrors.tuna.tsinghua.edu.cn/ubuntu/pool/xenial/ 這個路徑下的 main、restricted、universe、multiverse 這幾個目錄：

apt-get 工具會在這四個的目錄下自動檢索對應(yīng)的軟件包下載并安裝。

在一些特殊情況，比如機(jī)器網(wǎng)絡(luò)受限，但瀏覽器開了代理可以訪問外網(wǎng)的情況下。apt-get 無法從源里獲取軟件，你可以從這里手動找到對應(yīng)的軟件包下載下來然后使用 dpkg 安裝。

比如這里，手動找到 mysql 的安裝包路徑，再點(diǎn)擊就可以直接下載：

剛才說道 apt-get install 無法修復(fù)依賴，通過手動下載然后把這些缺失的安裝包裝上之后，就可以通過 apt-get 把剛才裝不上的包裝上。

這是非常合理合法的解決方案。

再補(bǔ)充一種合法技巧，可以嘗試用：

apt-get install 本地軟件包

這是因?yàn)椋?/p>

“依賴檢測”和“軟件安裝”不是 apt-get 做的，而是 dpkg 做的。依賴不滿足“自動修復(fù)依賴”才是 apt-get 做的。

所以，如果你下載了一個 deb 安裝包通過 dpkg 安裝，但依賴不滿足的話，他只會提示你依賴缺失，但他不會自動尋找并安裝依賴，雖然你仍然可以去下載安裝缺失的依賴，但他如果缺失十個八個的，你再手動下載然后 dpkg 安裝也不現(xiàn)實(shí)了。

舉個例子：我這里下載了一個搜狗輸入法的安裝包，dpkg -i 無法安裝，但是可以通過 apt-get install 裝上：

要注意：通過 apt-get 安裝本地軟件一定要寫路徑，相對絕對都可以，但不能只寫包名。不然它會去源里面找不會裝本地的。

上面的方案幾乎可以解決 80% 的安裝依賴問題?？偨Y(jié)一下：

• 安裝軟件就用：sudo apt-get install xxxx
• 遇到依賴問題：sudo apt-get -f install
• 如果有缺失無法安裝，就去網(wǎng)上下，缺什么下什么，下載下來后 sudo apt-get install ./xxxx 把缺的包安裝上，再裝原來的包。

接下來說說暴力的解決方案

之所以說暴力，是因?yàn)閯偛诺姆绞?，已?jīng)是在我的認(rèn)知里，工具和系統(tǒng)提供的自動化程序能做到的極限。

如果還是出現(xiàn)了依賴無法滿足的問題，比如什么即將安裝 xxxx 但是現(xiàn)在的系統(tǒng)內(nèi)的版本高于 xxxx。

一般這種情況，系統(tǒng)已經(jīng)不建議你再搞了，你如果非要硬來，很可能會破壞現(xiàn)有的程序依賴結(jié)構(gòu)。

• 運(yùn)氣好或者你手高，硬裝上一點(diǎn)問題沒有。
• 影響小一點(diǎn)，你裝了這個軟件，另一個軟件不能用或者會崩。
• 影響大一點(diǎn)，有些系統(tǒng)命令不好使了，界面卡死了，資源管理器崩了等等。
• 影響更大一點(diǎn)，裝完用著啥毛病沒有，重啟后卡在加載過程，再也進(jìn)不了系統(tǒng)。

“以上這些情況，我全部都遇到過！”

所以下面的搞法，你就當(dāng)學(xué)習(xí)知識或看我裝逼都行，自己實(shí)操，還是要謹(jǐn)慎地折騰。至少，別在客戶機(jī)器和生產(chǎn)環(huán)境的服務(wù)器上硬來。

暴力的解決方案有：

1. --ignore-depends，忽略依賴直接裝。
2. 解壓安裝包，刪掉依賴字段重新打包。
3. 修改系統(tǒng)中記錄的 status 文件。
4. 無視安裝失敗，直接運(yùn)行。
5. 直接拿到根目錄，就地解壓。
6. 改掉 dpkg 源碼，直接不檢測依賴。一個一個說：

1、--ignore-depends

這是所有暴力方案里技術(shù)門檻最低的一個，你可以通過 dpkg --help  查看 --ignore-depends 選項(xiàng)：

選項(xiàng)：
    ......其它選項(xiàng)
    --ignore-depends=<軟件包>,...
         忽略關(guān)于 <軟件包> 的所有依賴關(guān)系。
    --force-...

         忽視遇到的問題(參見 --force-help)。
    ......其它選項(xiàng)

這個選項(xiàng)可以指定要忽略的依賴包。所以安裝的時候如果依賴不滿足，你直接加上這個參數(shù)把依賴忽略的就完了：

當(dāng)然，安裝不會有任何問題，但是能不能用就看要造化了。

“并不是依賴不滿足，裝上就一定完全不能用”，有時候只是功能不全而已。

比如你裝了一個 QQ，它依賴 ffmpeg，你忽略了它后直接安裝使用很可能沒問題，但是一點(diǎn)擊視頻通話，程序立馬就崩掉了。（這是個假設(shè)，QQ 用啥不用啥我也不知道）

這個方案雖然門檻低，有個致命的缺陷就是太麻煩，我這里缺兩個，寫兩個 ignore 參數(shù)。安裝過程中經(jīng)常遇到那種一下子缺十個八個的，要寫十個八個這樣的參數(shù)屬實(shí)費(fèi)勁。

2、解壓安裝包，刪掉依賴字段重新打包

這個方案可以直接大刀闊斧地把軟件包的依賴全干掉，不過稍微需要點(diǎn)技術(shù)底子：

“首先你得會解壓安裝包，其次你得會制作安裝包。”

dpkg -X 只會解壓出安裝包的文件，無法解壓出安裝包帶的腳本和控制信息。

“右鍵”->“提取到此處”，解壓出來的control和data分開兩個壓縮包，也不是打包前完美的狀態(tài)。

這里要用的是

dpkg-deb -R sogoupinyin_xxxx.deb ./sogou

這樣解壓出來的就是 deb 在被打包前完完整整的樣子，我解壓了一個搜狗輸入法的安裝包為例：

其他的我們都不用管，直接打開 control 文件：

看到紅框的部分了吧，直接把這行全部干掉。然后再把拆出來的文件重新打回一個安裝包：

fakeroot dpkg-deb --build ./sogou mysogou.deb

這個自己打的 mysogou 安裝包，和搜狗原生安裝包唯一的區(qū)別就是沒有依賴。

這下就可以一路暢通無阻，直接裝完。

3、修改系統(tǒng)中記錄的 status 文件

和剛才那個方案思路差不多，只不過換了一個突破點(diǎn)，比剛才要更方便一點(diǎn)。

剛才我們突破的思路是：安裝包里記錄有對軟件依賴，全部干掉就沒有依賴了。

那么這個方案的思路則是：如果檢測依賴發(fā)現(xiàn)系統(tǒng)不滿足，我們給他偽造一個滿足的依賴環(huán)境不就完了！

剛才我們說的 control 文件，所有的 deb 文件都有，安裝過程中（不是安裝后也不是前），它就被記錄在了系統(tǒng)里的：/var/lib/dpkg/status 文件里。

這個文件里的內(nèi)容，也是 dpkg -l  命令顯示內(nèi)容的信息來源。

也是我們上面說的，依賴檢測時檢索系統(tǒng)內(nèi)是否滿足依賴的信息來源。

如果軟件通過 dpkg -r 卸載，這個 status 文件里的信息不會刪除，只會把 Status 字段改為： deinstall ok config-files。通過 dpkg -P 或者 dpkg --purge 才會把信息完全抹除。

所以，依賴不滿足的時候，你可以直接打開這個文件，仿照其他軟件的寫法，照抄一段加上，把文件名改為缺失的依賴包的名字就可以！dpkg 就會認(rèn)為，系統(tǒng)里有安裝這個包，從而解決依賴導(dǎo)致的無法安裝的問題。

同樣，如果出現(xiàn)依賴的包需要的版本不滿足的情況，你也可以直接找到文件里對應(yīng)的包的信息，改掉 Version 字段到一個滿足需求的版本就可以。

當(dāng)然，實(shí)際上系統(tǒng)里是沒有安裝這些庫的，我們只是騙過了 dpkg。

系統(tǒng)里的軟件信息一般都寫得特別多，這里簡單提供個樣例，實(shí)在不會抄系統(tǒng)的就抄這個：

Package: mtest
Priority: optional
Section: editors
Maintainer: Threedog Team <qiugeyafang@gmail.com>
Architecture: all
Version: 1.0.0
Homepage: http://www.threedog.top
Description: test

只要把 Package 換成缺失的依賴包的名字，加到 status 文件里就可以了。記得和其他軟件信息之間要有空行。

4、無視安裝失敗，直接運(yùn)行。

這個方案之所以可行，是 dpkg 對軟件安裝過程的執(zhí)行機(jī)制決定的。dpkg 對依賴的處理時機(jī)是：“先釋放文件，再檢測依賴，然后再完成最終配置。”

其實(shí) control 文件里還可以寫一個字段叫做預(yù)依賴：Pre-Depends 。這個字段的檢測級別和時機(jī)與 Architecture 字段相當(dāng)。寫在這個字段里面的依賴，如果檢測不滿足，安裝會直接中斷，不會釋放文件， status 中不會記錄，系統(tǒng)中也不會留下任何痕跡。

所以，當(dāng) dpkg 爆出依賴不滿足的問題的時候，其實(shí)包里的文件已經(jīng)釋放到系統(tǒng)里了，只不過沒有做后續(xù)的配置。比如：桌面圖標(biāo)配置、字體配置、文件關(guān)聯(lián)設(shè)置、啟動觸發(fā)設(shè)置等等。

但這并不妨礙你直接找到他的可執(zhí)行程序文件直接執(zhí)行。

如果你不知道他往系統(tǒng)里釋放了哪些文件：第一，可以解壓看下目錄結(jié)構(gòu)；第二，可以通過 dpkg --contents xxxx.deb 查看包里包含哪些文件。

也可以用 dpkg -S 軟件名 查看已經(jīng)安裝的軟件在系統(tǒng)里裝了哪些東西。

然后找到二進(jìn)制可執(zhí)行文件，一般都會往 /usr/bin/ 下面放一個，運(yùn)氣好的話直接執(zhí)行有可能能跑起來。

5、暴力解壓

這個方案屬實(shí)有點(diǎn)過于暴力并且不合理。直接把安裝包移動到根目錄下，然后直接 dpkg -X 解壓到當(dāng)前。然后像剛才一樣找二進(jìn)制可執(zhí)行程序調(diào)用。

前提是你知道這軟件包里有什么并且明確它不會影響什么的話。

不然如果解壓出的文件破壞了系統(tǒng)的重要文件，那直接就是不可逆的毀降維打擊。

而且這么搞完，如何卸載也是一個問題......

6、改 dpkg 源碼

這是技術(shù)上最硬核的解決方案。

主要操作方法如下：

從這個地址： https://git.dpkg.org/git/dpkg/dpkg.git 克隆下來 dpkg 源碼，在源碼里的 packages.c 里面找到這個 dependencies_ok 函數(shù)。甭管它里面寫了多少東西，直接在最開頭給它 return DEP_CHECK_OK;  或者 return 2; 反正就是個枚舉。

然后把項(xiàng)目編譯一下生成自己的 dpkg 用就可以。

我這里自己編譯的 dpkg 多加了一行輸出，效果明顯一點(diǎn)：

這個函數(shù)改的是對 Depends 字段的依賴檢測。

如果是預(yù)依賴 Pre-Depends 字段，要改的是另一個名為 depisok 的函數(shù)。

關(guān)于 dpkg 項(xiàng)目源碼的編譯，用的是 Linux C 項(xiàng)目 automake 那一套。C/C++ 老炮閉著眼就編過去了，沒入門的萌新連怎么下手都不知道。像我這種剛?cè)腴T的菜雞，就得每走一步拿小本本記一下一點(diǎn)，也想這樣玩一下的小伙伴可以參考： https://blog.csdn.net/Three_dog/article/details/103418141 

有了這個自己編譯的 dpkg，所有軟件都可以無阻礙安裝。

不過至于裝完能不能用，會不會有啥問題，恐怕就得看造化了。

dpkg 的解決方案全部講完，說說 rpm

之所以對 rpm 只字未提有兩個原因：

“一是我對它的熟悉程度，遠(yuǎn)沒有 dpkg 這么深入。”

“二是它真的，相比 dpkg，難用的令人抓狂。”

在合法的解決方案上，rpm 和 dpkg 沒有太大區(qū)別。你只需要把上面的對照方案，dpkg + apt-get 換成 rpm + yum 就可以。我們不多贅述了。

主要說說非法方案：

rpm 的機(jī)制，幾乎導(dǎo)致我所有的非法方案完全不可用！

方案一

可用的只有這一個：忽略依賴，這是在 rpm 上唯一可以對標(biāo)的非法解決方案，只需要把 --ignore-depends 換成 --nodeps 就可以。

其他的，幾乎都不行：

方案二

rpm 打包的時候，配置信息寫在一個 .spec 文件里，對標(biāo)上面的 control 文件，這個文件的寫法規(guī)范惡心程度就不說了，重要的是它無法從打好的 rpm 安裝包里逆向解壓出來。

你只能用 rpm --scripts -qa xxxx.rpm 來查看，而且看到的和它原來真正的寫法有很大不同，你甚至可以理解成用 objdump 看可執(zhí)行程序的感覺。

這個機(jī)制，導(dǎo)致了上面的方案二（解壓安裝包，刪掉依賴字段重新打包）被斃掉。

方案三

rpm  安裝到系統(tǒng)中的軟件，也有一個文件統(tǒng)一管理，但是！它丫的天殺的居然用的是一個數(shù)據(jù)庫管理的：

這是編譯 rpm 時候 configure 參數(shù)，這三種數(shù)據(jù)庫編譯時可選，安裝版一般是Berkeley DB。

用數(shù)據(jù)庫管理，就存成二進(jìn)制數(shù)據(jù)文件了！就不像我們剛才的 status 直接修改文本了，而惡心就惡心在（我水平太次也是一方面），這三種數(shù)據(jù)庫我折騰了半天也沒找下工具能對它們增刪改查！

換句話說這個數(shù)據(jù)庫內(nèi)容的操作，只有 rpm 可以，不面向用戶。

因此，上面的方案三（修改系統(tǒng)中記錄的 status 軟件）也被斃掉了

方案四

rpm 的安裝只有一種依賴檢查的時機(jī)，就是在釋放文件前。

所以如果出現(xiàn)依賴問題，包里面的文件一滴也不會漏到系統(tǒng)上來，上面的方案四（無視安裝失敗，直接運(yùn)行）也被斃掉了。

方案五

直接暴力解壓是可以的。不過上面也說了，這實(shí)在是下下下下下下策。

方案六

最后一個，改 rpm 的源碼。

以我的水平，說實(shí)話還沒有權(quán)利對一個成熟的開源項(xiàng)目源碼評頭論足，但一個不爭的事實(shí)是：我想像上面那種改 dpkg 的改法改 rpm 的源碼。折騰了一圈子確實(shí)沒找到咋改。

所以方案六（修改項(xiàng)目源碼）也基本宣告流產(chǎn)。

我想這也是很多人認(rèn)為 dpkg 比 rpm 好用太多的原因之一。

rpm 把數(shù)據(jù)全部用數(shù)據(jù)庫管理起來，看似增強(qiáng)了安全性，但是對于酷愛折騰的 Linuxer 來說，這種可操控性上帶來的降維打擊簡直無法忍受。

除此之外，它還有非常難用的命令組合；令人沮喪的軟件源配置方法；以及地獄難度的打包規(guī)規(guī)范；打包還不留原文件等等讓人覺得它難用的特性在里面?。ù虬?guī)范真的是折磨人！一不小心打錯了，連原文件都沒得咯！一個都沒得咯！?。?/p>

以上，就是以我現(xiàn)有的水平，可以提供的所有針對 Linux 鬼畜逆天級的軟件依賴關(guān)系的解決方案?？梢钥吹贸鰜?，有些方案是吃一點(diǎn)兒技術(shù)底子的。

很多技術(shù)問題都是這樣，當(dāng)你對準(zhǔn)某一方向鉆研到一定深度的時候，很多在常人看來不可能實(shí)現(xiàn)的操作，在你手里就可以為所欲為?。ㄎ移奚埔荩杭幸稽c(diǎn)，登峰造極）

而且我相信，肯定還有我沒想到的好辦法可以解決這些問題，有可以提供方案或者思路的大佬請一定賜教！

最后，再糾正一個很多人的認(rèn)知誤區(qū)

直到現(xiàn)在，有幾乎 80% 的科普性文章在介紹 rpm 和 deb 文件的時候，把它們與 RedHat 和 Debian 死死的綁定在一起。以至于很多人潛意識里認(rèn)為：Debian 系只能用 dpkg，RedHat 系只能用 rpm。

其實(shí)完全不是。他們的關(guān)系，是系統(tǒng)和軟件的關(guān)系，僅僅是Debian 自帶 dpkg 和 apt，RedHat 自帶 rpm 和 yum 而已。

Ubuntu 完全可以通過 sudo apt-get install rpm 安裝一個 rpm 系統(tǒng)，然后通過 rpm 安裝各種 rpm 格式的安裝包。

而 CentOS，也完全可以通過編譯安裝（因?yàn)?yum 源里沒有 dpkg，噗~） 一個 dpkg，然后安裝各種 deb 格式的安裝包。

只要安裝的軟件所釋放出文件沒有沖突，兩者在系統(tǒng)上的相處模式，甚至可以用舉案齊眉、相敬如賓來形容。

根本不像大多數(shù)人認(rèn)為的那樣老死不相往來：