为什么 Linux 打包软件时不将依赖一起打包进去？

[yao990]

为什么 Linux 打包软件时不将依赖一起打包，安装时再检测此依赖是否已存在，如存在则放弃安装。

现有的方式是各是各的，打包软件时给出一张表:我需要 xxx 依赖，然后系统自行安装，这就导致如果当前源里没有这个依赖，则软件安装失败，有些软件甚至依赖好多个源。。

[xupefei]

有类似的，比如 flatpak、snap、appimage。
但是工作模式和 lz 说的有点儿不一样，上面这些自带依赖，而且依赖随着 app 走，不会进入系统。

[WebKit]

所以现在有很多 AppImage 格式的应用了

[SenLief]

现在都采用 Appimage，就是差不多你说的这种情况。

[Sasasu]

> 有些软件甚至依赖好多个源

ppa 源的受害者

[jim9606]

因为有些依赖是不适合自带依赖了，例如几乎所有程序都要用的 glibc，因为强行跨版本共存会有很多问题
如果自带依赖，那通常就是全部依赖都带上（ flatpak、snap、appimage、docker ）而不是装一半检测一半。
而且你也不知道你自行安装的依赖会不会破坏其他软件的依赖关系，例如你安装了低版本 libqt5 导致发行版别的 qt 应用找不到符号开不了。所以还不如安装的时候通过包管理器告知缺少依赖，安装发行版维护的依赖包。
最麻烦但问题最少的实践是针对发行版各个版本维护各自的软件源，例如 docker 和 cuda 的官方软件源，就是工作量比较大，或者想办法进入发行版仓库，由发行版团队去解决部署的问题。

[ipwx]

然后多个软件依赖同一个库的不同版本，GG。

你安装的乱七八糟的软件打包的依赖和系统其它软件依赖的这个库版本不一样且不兼容，GG。
----

解决方案是 Docker，是 Flatpak 等手段。他们都不是安装到系统，而是安装到一个专用的目录，或者虚拟环境。

[jinsongzhao]

Linux 支持静态编译，把你要的库都打包到一个执行文件，也可以指定调用的动态库路径，调用指定版本的动态库，对于小的库，静态编译没什么问题。但不做静态编译，甚至只给源代码，是开源的传统，它有利于开源生态吧。

[PTLin]

一种是向你想得那样把依赖打包到一起，缺点就是软件包大，优点就是好分发，像是 Flatpkg 还支持一些安全性质。
另外一种是让软件的源变得健壮起来，尽可能包含所有软件，并且消除依赖问题。
所以我选择了 Manjaro

[sagaxu]

举个例子，官方哪个源里的哪个软件不能自洽？

[raysonx]

静态链接不仅仅是安装包大的问题。假设有 100 个软件都用到了 openssl，然后某一天 openssl 爆出一个漏洞。如果是用动态链接则只需要升级动态库就可以了，而静态链接则需要重新编译这 100 个软件再进行逐一升级。

[crella]

我觉得大部分 linux 上的软件包都有某某协议才是关键点。

不同协议的软件你打包在一起，不方便吧。

[4ever911]

dll hell

[loading]

为啥我感觉回到了 15 年前左右的 rpm 时代。

[cyspy]

存在自己改编译配置的空间

[vcfvct]

貌似 ubtuntu 20.04 的 default 已经从 apt 到 snap 啦。

[DefoliationM]

可以节省不少空间,而且现在有 snap,appimage,flat 多种选择 所以...

[msg7086]

正常的发行版打包都是能自我满足的，少数第三方因为结构复杂所以有时候没办法只能从多个源里抽包。
举个例子，我在维护的一个软件包依赖某个 dmo 打包的版本。我当然可以自己维护一套，但是那就意味着往下整个依赖树都要变成我来维护了。所以暂时还没决定要不要这么做。

[reus]

用 arch，用 manjaro，你就不会对 linux 有这样的认识了。

[electriccubes]

> 如果当前源里没有这个依赖

这显然是打包者的责任了……

> 安装时再检测此依赖是否已存在，如存在则放弃安装

这句话我不太明白什么意思……

[vk42]

@electriccubes 这为啥会是打包者的责任……打包者能管所有安装用户的系统加了哪些源么？