Arch linux 软件依赖冲突怎么解决的

Arch总是最新版,不知道会不会出现 A 依赖 B , C 也依赖 B ,B 升级到新版 B1 ,假设 A 更新比较快也升级到 A1 ,但是 C 的开发比较慢,B1 下无法工作,这时怎么办? 极端情况下,如果 B 是 linux 内核呢?

打 patch

如果A是闭源的商业软件呢?

极端情况会留个老版本,比如你可以安装 Python2,Java8,等等

B 如果是内核的话,倒是可以选择 linux-lts 缓一缓,可以参考一下 https://wiki.archlinux.org/index.php/Kernel_(简体中文)

1赞

嗯嗯 如果能具体操作实例就好了,比如这个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代替.

4赞

精辟,谢谢!

所谓容器到底是什么呢,总是不太明白。看起来似乎就是把应用和所需要的库都打包到一起,那这样做和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赞