有些软件使用系统的库版本，那就需要根据不同的发行版分别编译；有些软件自带了一些依赖库，就会在启动脚本中为自己设置环境变量，优先找自带的库

不解决依赖冲突。所以任何依赖冲突都会直接出错退出，让用户自己想办法去

原来启动脚本还可以控制这个，学习了

想尝试学下打包，发现依赖冲突很严重，找到依赖，换个系统就启动不了了。。。

这种包估计别人打包好了就是为了方便自己用的，没准备发布。

自己解决也不难，为了避免和系统依赖冲突，自己设置一个LD_LIBRARY_PATH环境变量就行了，冒号分割多个路径，如: 

LD_LIBRARY_PATH="/path/to/lib:/usr/lib/:/usr/lib64/:${LD_LIBRARY_PATH}" /path/to/execution

环境变量设置和执行命令放同一行执行，可以临时只对这一条命令生效，执行完毕环境环境变量就被还原，不干扰其他程序。

如果期望自己引入系统级别依赖，又不会和系统软件包冲突，也可以把自己的路径添加到/etc/ld.so.conf.d/*.conf文件也行，比如:

echo '/usr/local/lib' | sudo tee -a /etc/ld.so.conf.d/local.conf

sudo ldconfig

这样所有的软件都会额外在/usr/local/lib/路径下去找依赖，你可以把自己编译的依赖扔到/usr/local/lib(/usr/local通常也是configure的默认路径)，不过这样有一定的危险性，改动系统目录和系统配置对系统都会有一定破坏作用，你必须自己确保你引入的依赖可以兼容其他程序，好处就是不需要自己设置环境变量，所有程序都受益，而且不会和其他deb包冲突

自己设置LD_LIBRARY_PATH临时用于一个程序这个方法看着不错。

/etc/ld.so.conf.d/写.conf文件的效果好像和/etc/profile里写环境变量差不多，还只能写.so文件的路径。

苹果系统下的软件为什么都非常大，就是因为大多应用都自己包含了几乎所有的依赖。linux或mac（类unix）与windows在这方面的机制不同，所以windows在使用久了后，windows目录会变得很大，很多应用程序直接将一些库文件放到里面去了，两种机制各有利弊。windows安装软件简单，linux安装软件麻烦，但卸载后系统较干净。

是这个道理，所以windows只适合桌面端。微软的服务器都是用的linux系统

很好的问题。

linux下的appimage包与mac下的dmg包感觉类似，都是把所有软件的依赖扔进包里

为什么应用商店的应用不都打包为appimage呢

常规打包软件100M，打包appimage估计就得300M以上了。

但是就没有依赖关系了啊,我觉得依赖这个问题非常麻烦, 软件依赖库, 库最后依赖libc,libc又依赖内核, 内核天天更新, 这又是内核的问题, 天天升级,我超