史上最硬核的rpm和dpkg依赖问题解决方案_dpkg 依赖(2)，2024年最新软件测试高级架构进阶之数据传输与序列化

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新软件测试全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注软件测试）

正文

这个方案虽然门槛低，有个致命的缺陷就是太麻烦，我这里缺两个，写两个ignore。安装过程中经常遇到那种一下子缺十个八个的，要写十个八个这样的参数属实费劲。

2、解压安装包，删掉依赖字段重新打包

这个方案可以直接大刀阔斧地把软件包的依赖全干掉，不过稍微需要点技术底子：

「首先你得会解压安装包，其次你得会制作安装包。」

dpkg -X 只会解压出安装包的文件，无法解压出安装包带的脚本和控制信息。

右键提取到此处，解压出来的control和data分开两个压缩包，也不是打包前完美的状态。

这里要用的是

dpkg-deb -R sogoupinyin_xxxx.deb ./sogou

这样解压出来的就是deb在被打包前完完整整的样子，我解压了一个搜狗输入法的安装包为例：

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

看到红框的部分了吧，直接把这行全部干掉。然后再把拆出来的文件重新打回一个安装包：

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

这个自己打的mysogou安装包，和搜狗原生安装包唯一的区别就是没有依赖

这下就可以一路畅通无阻，直接装完。

3、修改系统中记录的status文件

和刚才那个方案思路差不多，只不过换了一个突破点，比刚才要更方便一点。

刚才我们突破的思路是：安装包里记录有对软件依赖，全部干掉就没有依赖了。

那么这个方案的思路则是：如果检测依赖发现系统不满足，我们给他伪造一个满足的依赖环境不就完了！

刚才我们说的control文件，所有的deb都有，安装过程中（不是安装后也不是前），他就被记录在了系统里的：「**/var/lib/dpkg/status」**文件里。

这个文件里的内容，也是dpkg -l 命令显示内容的信息来源。

也是我们上面说的，依赖检测时检索系统内是否满足依赖的信息来源。

如果软件通过dpkg -r卸载，这个status文件里的信息不会删除，只会把Status字段改为：deinstall ok
config-files。通过dpkg -P或者dpkg --purge才会把信息完全抹除。

所以，依赖不满足的时候，你可以直接打开这个文件，仿照其他软件的写法，照抄一段加上，把文件名改为缺失的依赖包的名字就可以！dpkg就会认为，系统里有安装这个包，从而解决依赖导致的无法安装的问题。

同样，如果出现依赖的包需要的版本不满足的情况，你也可以直接找到文件里对应的包的信息，改掉Version字段到一个满足需求的版本就可以。

当然，实际上系统里是没有安装这些库的，我们只是骗过了dpkg。

系统里的软件信息一般都写得特别多，这里简单提供个样例，实在不会抄系统的就抄这个：

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、无视安装失败，直接运行。

这个方案之所以可行，是dpkg对软件安装过程的执行机制决定的。dpkg对依赖的处理时机是：「先释放文件，再检测依赖，然后再完成最终配置。」

其实control里还可以写一个字段叫做预依赖：Pre-Depends这个字段的检测级别和时机与“架构Architecture”字段相当。写在这个字段里面的依赖，如果检测不满足，安装会直接中断，不会释放文件，status中不会记录，系统中也不会留下任何痕迹。

所以，当dpkg爆出依赖不满足的问题的时候，其实包里的文件已经释放到系统里了，只不过没有做后续的配置。比如：桌面图标配置、字体配置、文件关联设置、启动触发设置、等等等等。

但这并不妨碍你直接找到他的可执行程序文件直接执行。

如果你不知道他往系统里释放了哪些文件，第一，可以解压看下目录结构，第二，可以通过dpkg --contents xxxx.deb查看包里包含哪些文件。

也可以用dpkg -S +软件名查看已经安装的软件在系统里装了哪些东西。

然后找到二进制可执行文件，一般都会往**/usr/bin/**下面放一个，运气好的话直接执行有可能能跑起来。

5、暴力解压

这个方案属实有点过于暴力并且不合理。直接把安装包移动到根目录下，然后直接dpkg -X解压到当前。然后像刚才一样找二进制可执行程序调用。

前提是你知道这软件包里有什么并且明确它不会影响什么的话。

不然如果解压出的文件破坏了系统的重要文件，那直接就是不可逆的毁降维打击。

而且这么搞完，如何卸载也是一个问题…

6、改dpkg源码

这是技术上最硬核的解决方案。

主要操作方法如下：

从这个地址：https://git.dpkg.org/git/dpkg/dpkg.git

clone下来dpkg源码，在源码里的packages.c里面找到这个dependencies_ok函数。甭管他里面写了多少东西，直接在最开头给他return DEP_CHECK_OK; 或者**return 2;**反正就是个枚举。

然后把项目编译一下生成自己的dpkg用就可以。

我这里自己编译的dpkg多加了一行输出，效果明显一点：

这个函数改的是对Depends字段的依赖检测

如果是预依赖，Pre-Depends: 字段，要改的是另一个名为depisok的函数。

关于dpkg项目源码的编译，用的是Linux
c项目automake那一套。C/C++老炮闭着眼就编过去了，没入门的萌新连怎么下手都不知道。像我这种刚入门的菜鸡，就得每走一步拿小本本记一下一点，也想这样玩一下的小伙伴可以参考：https://blog.csdn.net/Three_dog/article/details/103418141

有了这个自己编译的dpkg，所有软件都可以无阻碍安装

不过至于装完能不能用，会不会有啥问题，恐怕就得看造化了。

二、解决rpm依赖包

之所以对rpm只字未提有两个原因：

「一是我对它的熟悉程度，远没有dpkg这么深入。」
「二是它真的，相比dpkg，难用的令人抓狂。」

在合法的解决方案上，rpm和dpkg没有太大区别。你只需要把上面的对照方案，dpkg+apt-get换成rpm+yum就可以。我们不多赘述了。

主要说说非法方案：

rpm的机制，几乎导致我所有的非法方案完全不可用！

方案一

可用的只有这一个：忽略依赖，这是在rpm上唯一可以对标的非法解决方案，只需要把–ignore-depends 换成**–nodeps**就可以。

其他的，几乎都不行：

方案二

rpm打包的时候，配置信息写在一个**.spec文件里，对标上面的control**文件，这个文件的写法规范恶心程度就不说了，重要的是它无法从打好的rpm安装包里逆向解压出来。

你只能用rpm --scripts -qa xxxx.rpm来查看，而且看到的和它原来真正的写法有很大不同，你甚至可以理解成用objdump看可执行程序的感觉。

这个机制，导致了上面的方案2（解压安装包，删掉依赖字段重新打包）被毙掉。

方案三

rpm 安装到系统中的软件，也有一个文件统一管理，但是！它丫的天杀的居然用的是一个数据库管理的：

这是编译rpm时候configure参数，这三种数据库编译时可选，安装版一般是Berkeley DB。

用数据库管理，就存成二进制数据文件了！就不像我们刚才的status直接修改文本了，而恶心就恶心在（我水平太次也是一方面），这三种数据库我折腾了半天也没找下工具能对他们增删改查！

换句话说这个数据库内容的操作，只有rpm可以，不面向用户。

因此，上面的方案3（修改系统中记录的status软件）也被毙掉了

方案四

rpm的安装只有一种依赖检查的时机，就是在释放文件前。

所以如果出现依赖问题，包里面的文件一滴也不会漏到系统上来，上面的方案4（无视安装失败，直接运行）也被毙掉了。

方案五

方案5，直接暴力解压是可以的。不过上面也说了，这实在是下下下下下下策。

方案六

最后一个，改rpm的源码。

以我的水平，说实话还没有权利对一个成熟的开源项目源码评头论足，但一个不争的事实是：我想像上面那种改dpkg的改法改rpm的源码。折腾了一圈子确实没找到咋改。

所以方案6（修改项目源码）也基本宣告流产。

我想这也是很多人认为dpkg比rpm好用太多的原因之一。

rpm把数据全部用数据库管理起来，看似增强了安全性，但是对于酷爱折腾的Linuxer来说，这种可操控性上带来的降维打击简直无法忍受。

除此之外，它还有非常难用的命令组合；令人沮丧的软件源配置方法；以及地狱难度的打包规规范；打包还不留原文件等等让人觉得它难用的特性在里面！（打包规范真的是折磨人！一不小心打错了，连原文件都没得咯！一个都没得咯！！）

以上，就是以我现有的水平，可以提供的所有针对Linux鬼畜逆天级的软件依赖关系的解决方案。可以看得出来，有些方案是吃一点儿技术底子的。
很多技术问题都是这样，当你对准某一方向钻研到一定深度的时候，很多在常人看来不可能实现的操作，在你手里就可以为所欲为！（我妻善逸：集中一点，登峰造极）
而且我相信，肯定还有我没想到的好办法可以解决这些问题，有可以提供方案或者思路的大佬请一定赐教！

最后，再纠正一个很多人的认知误区：

直到现在，有几乎80%的科普性文章在介绍rpm和deb的时候，把他们与redhat和debian死死的绑定在一起。以至于很多人潜意识里认为：debian系只能用dpkg，红帽系只能用rpm。

其实完全不是。他们的关系，是系统和软件的关系，仅仅是debian自带dpkg和apt，红帽自带rpm和yum而已。

ubuntu完全可以通过 sudo apt-get install rpm 安装一个rpm，然后通过rpm安装各种rpm格式的安装包。

而centos，也完全可以通过编译安装（因为yum源里没有dpkg 噗~） 一个dpkg，然后安装各种deb格式的安装包。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

而centos，也完全可以通过编译安装（因为yum源里没有dpkg 噗~） 一个dpkg，然后安装各种deb格式的安装包。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）
[外链图片转存中…(img-2W9Oszlo-1713473617011)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！