其实它源于一条群友问。简单说就是hplip（HP打印机实用程序）不认为Kali是Debian发行版。那时候说的是：改/etc/os-release到DEBIAN，不行的话走AUR编译成Arch的安装包，自己手动解压到对应位置。

我感觉我的描述有点太过简略，且极具误导性，所以发博客了。

什么情况下应该使用这种邪道方法

安装包选择顺位

在同一发行版：发行版官方源 > 适配发行版的第三方源 > 上游发行版官方源（older > 同级） > 适配上游发行版的第三方源（older > 同级） > 适配当前版本发行版的可执行文件安装程序（.run） > 适配兼容于当前版本发行版的可执行文件安装程序（.run） > 适配上一版本发行版的可执行文件安装程序 > 适配兼容于上一个版本发行版的可执行文件安装程序 > 手动编译

不同发行版（新旧顺序看内核版本）：（同一发行版） > 旧发行版的安装包 > 新发行版的安装包

什么时候使用

很简单，官方提供的安装方法全部失效的时候。

使用前的重要说明

• 不要作死在每个包都用这种方法！这只是临时方案！发行版太老就更新发行版！！！！！！
• 不要试图替换任意已存在的文件！
• 不要应用在内核、C库（libc）、编译工具链（gcc等）上！版本不够就更新发行版！
• 不要在任意生产环境应用该方案！！！！！该方案只是临时方案！
• 做好备份！做好系统其它部件被搞炸的准备！
• 不要使用NixOS等不支持FHS的发行版提供的包！

具体操作方法

预准备

1. 安装依赖。看依赖哪些包，装好一切。
2. 安装zstd（新deb/Ubuntu deb，Arch）、brotli（没见有人在用）、gzip（大部分包管理器使用的压缩格式）等压缩程序。

解压缩

常规状况

找到对应的包，下载并解压。

在解压后你会发现这么一个结构：一个是模拟的根目录（软件包管理器会将里面的东西复制到对应位置），一个是配置文件存放处（主要是告诉包管理器前中后期都该做什么，以及包的基础检索信息。一般使用文本编辑器打开就好）。（例如deb、rpm）

你要做的就是像软件包管理器一样执行好每个步骤到设置完成。

AUR等来源的包（脚本）

偷懒

你需要一个环境来运行脚本打包。一般的，你需要对应环境的容器，例如Arch可以参照安装Arch Linux的方法（使用arch-install-scripts，从pacstrap开始）安装容器，并从AUR下载脚本运行makepkg（你仍然需要在容器里安装一遍依赖，而且，内核头（linux-headers）需要自己从宿主里提取复制到容器里的对应位置）。然后按常规状况提供的方案继续。

不需要对应环境

脚本本质上还是脚本。对Debian来说，你可以试试makedeb等工具，并将依赖什么的自己安装好后删掉字段。此时它大概率能跑起来并生成对应的包。

为什么我说它灵

原因非常简单，这玩意儿完全绕过了包管理器。

对于点发行版来说，这倒是不会出现什么问题，但对于滚动发行的发行版来说，这很显然是在作死，你永远无法预知什么奇奇怪怪的依赖会因为行为改变而导致软件崩掉。

在安全层面上讲，绕过包管理器会导致你永远会滞后的获取上游的安全补丁，因为编译需要时间，且包管理器会帮你配置好软件的参数。绕开它相当于一切的一切都需要自己去搞。

至于上文所强调的不要应用于关键库，这个是有相关错误实践的。他炸掉的原因恰恰是绕开了发行版的包管理器系统。即使他真的将glibc升上去了，他的业务肯定也会有潜在的暴雷风险（在原文章中，系统整体的依赖是基于旧版本的glibc上的，不升级其它包会有潜在的因行为改变而导致的下游行为异常的状况，且最终会（风险发生概率）叠加地影响业务）。