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

[yao990]

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

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

[k9982874]

@vk42 打包者需要维护包依赖，确保打的包至少在官方默认安装环境下可用，否则打包还有什么意义？

用户自己作死修改源列表不在讨论范围。

[LokiSharp]

没必要一起打包啊

[zjsxwc]

也就几次 make 命令搞定的事情，依赖缺什么装什么呗，完全打包好开箱即用不用依赖的大概只有 java 程序了吧

[msg7086]

@vk42 打包者的责任关用户加了哪些源什么事。
打包者要做的是保证用户在只有官方源和你的源的时候软件包要正常安装。
比如你用 Debian，然后用了 sury 的 PHP 源，那 sury 就要保证你在只有 Debian 官方源和 sury 源的前提下，他的 PHP 包能安装。至于你再去开了一堆其他的源，这关 sury 啥事。

所以「如果当前源里没有这个依赖」这个假设，在正常维护的源里是不应该存在的。这个依赖要么是发行版提供，要么是打包者提供。

[yulihao]

@Sasasu ppa 源国内访问好成问题额

[masker]

@vcfvct snap 有个问题就是…jetbrains 家的产品，不支持中文输入法～

[passerbytiny]

你是要像 Android/iOS 那样打包吗，先去看看你的手机，还有没有“仅在 wifi 环境下下载安装包”的选项。将依赖包一起打到发行包上，确实省事了，但那会造成安装包和安装后应用的体积剧增，并且大部分剧增的空间还是重复的。手机端因其特殊性——不能在安装时联网从远程库下载依赖包而且也不能把所有依赖包都预先安装的操作系统上、使用群体是消费者——所以不得不使用那种打包方式，而 Linux 是服务器且其使用群体是开发者，就别想跟小白那样省事了。

[HuHui]

npm:喵喵喵？

[pythonee]

@reus
@PTLin

最近 Manjaro 的曝光率很高阿

[lewis89]

所以 docker 出来了 ，解决这些破烂依赖的 神器

[julyclyde]

lz 没分清打包和源码发行
后者肯定不带依赖，只带依赖检测机制。开发者没必要对外部依赖的质量负责，只需要使用就行了
前者带依赖声明，可以由包管理机制负责安装上去，版本协调和质量都由打包者负责

全包的场景，可以维持依赖关系的稳定性，但缺点是开发方同时还得负责外部依赖的版本管理

[yao990]

@electriccubes 第二句的意思是，安装时再在系统中检测所需要的依赖是否已在系统中存在并符合要求，如果所需要的依赖已存在并且符合要求，就不在重复安装这些依赖

[TangMonk]

@lewis89 #30 这和 docker 两码事

[chocotan]

用了十年 linux 桌面了
目前还没有遇到过楼主说的情况
当然也有可能是我安装的软件少

[momocraft]

打包我理解为已经编译好了，编译好的东西再要检测依赖的复杂度可能超过你想象。

一般发行版 repo 有软件就会有其依赖，你说的“现有方式”更像用户配置 repo 出错时的现象。

[chocotan]

@chocotan 以前用 ubuntu 的时候经常遇到依赖的问题，现在用了 arch，很省心

[passerbytiny]

@lewis89 #23 了解以下 Docker 镜像的分层，或者制作一个简单的 Dockerfile 吧。Docker 只不过是把所有层（类似于所有依赖）一并打包，虽然使用者看不到依赖，但依赖仍然存在。

Docker 镜像包的体积，那可是相当感人，一个 Docker 镜像就是一个准操作系统，镜像制作者必须小心的处理才能使得镜像包的体积不那么非人。原本就有几百 M 的应用软件做个 Docker 镜像再额外多几十 M 没啥问题，但原本就十来 M 甚至不足 1M 的工具软件打成 Docker 镜像，原始依赖和额外依赖加起来变成上百 M，那就是问题了。

[BOYPT]

先问是不是再问为什么。
Mysql/JREJDK/Oracle 那么一大堆的 binary dis 包里面的都是静态编译依赖的。

[crc8]

@electriccubes 后一句意思是在安装过程中才去检测是否存在不合理。

[lexuskingxx]

可以试试 manjaro