Arch总是最新版，不知道会不会出现 A 依赖 B , C 也依赖 B ，B 升级到新版 B1 ，假设 A 更新比较快也升级到 A1 ，但是 C 的开发比较慢，B1 下无法工作，这时怎么办？ 极端情况下，如果 B 是 linux 内核呢？
打 patch
如果A是闭源的商业软件呢？
极端情况会留个老版本，比如你可以安装 Python2，Java8，等等
嗯嗯 如果能具体操作实例就好了，比如这个vpn软件老是抱怨动态链接库找不到 https://docs.hillstonenet.com/en/Content/7_VPN/SSL_VPN_Client_L.htm
能不能把商业闭源软件和它的依赖打包到一个appimage呢
感觉这种情况应该不存在啊，除非只更新一部分包，这样的话很容易滚挂的。
1 个赞
问题就是一些闭源的软件，看我找到这个
这种你找找 AUR，有没有老版本的依赖库。不行就自己写个 PKGBUILD。
1 个赞
没法解决.
举一个简单的例子, 两个软件分别依赖libfoobar的1.0版本和2.0版本. 在不单独处理的时候, Arch里只能选一个版本装, 不然他们的文件就互相冲突了.
Arch要打包一个软件的不同版本, 一般在打包过程时把产物文件重命名一下, 避免相互冲突, 然后依赖这个软件包的包在这个改好的PKGBUILD的基础上重新打包. 如果你的软件依赖十分复杂, 得自己重新打一堆包, 就特别麻烦.
Guix/Nix的机制可以很好的解决这个问题. 他们的软件实际在一个用sha256和文件名做区分的store里, 然后symlink出来一个软件包的集合(叫profile), 这样相同软件的不同版本可以很简单的互存.
但是Guix/Nix因为没有/usr/bin /usr/lib 等常见发行版的目录结构. 要运行写死了依赖的闭源软件来说十分麻烦.
所以还是王道征途, 用Docker吧. 觉得Docker太重量的可以用Singularity代替.
6 个赞
精辟，谢谢！
所谓容器到底是什么呢，总是不太明白。看起来似乎就是把应用和所需要的库都打包到一起，那这样做和Windows上那种受人诟病的自带运行库的庞大exe文件又有什么区别呢？
“把应用和所需要的库都打包到一起” 是一种分发策略, 而容器是用来实现这种策略的工具. 用容器使用linux 的mount namespace, 让容器内的软件只能"看"到我们给定的依赖, 实现在不干扰宿主的前提下使用特定的软件. Docker是在linux namespace的基础上简化了不少步骤(比如docker提供各种发行版的image, 可以直接在image上用包管理器装我们需要的依赖. 还有Docker帮你设立端口转发用的iptables规则, docker网桥和veth pair等)
确实, 这是学习了Windows的自带运行库的策略. 或许"令人诟病" 但是 “各有千秋”.
大部分linux发行版的策略是尽可能共用动态依赖库, 节省空间和应用的加载时间, 这样做还有个好处: 假设某基础依赖库libxyz被爆出严重CVE(安全漏洞), libxyz只需发布一个bugfix版本, 发行版跟进打包这个版本后, 所有动态链接到这个libxyz的软件都会自动享受到这个安全更新.
但这样重度互相耦合的坏处就是一个库升级, 依赖他的软件就可能会崩. 比如libx11更新导致Emacs无法使用输入法
1 个赞