解决冲突的最好办法,就是不要出现冲突
大概率会使用玲珑软件管理工具,但是apt一些常用软件仍然会保留apt的使用。
解决冲突的最好办法,就是不要出现冲突
好像啥都说了,又好像啥也没说。但确实靠谱
重型开发工具,生产力软件 -> docker
轻型软件,非生产力软件 -> flatpack
玲珑其实就是基于docker开发的一套玩意儿
换成Windows10最靠谱
依赖冲突的本质是不同软件包依赖同一个软件包的不同版本,而被依赖的不同版本的软件包需要将文件装到相同的位置。Nix 彻底解决了这个问题,因为一个软件包的不同版本不会被安装到相同的位置,任何一个微小的改动都会改变它在 /nix/store 中的路径,而通过 /nix/store 的路径可以准确地引用一个确定的版本。
不过,你既然都可以接受自己打包了,传统包管理器改包改个路径理论上也是可行的,但 Debian 系的打包确实比较复杂,你可能只是想要个比较容易打包的包管理器
依赖冲突的本质是不同软件包依赖同一个软件包的不同版本,而被依赖的不同版本的软件包需要将文件装到相同的位置。Nix 彻底解决了这个问题,因为一个软件包的不同版本不会被安装到相同的位置,任何一个微小的改动都会改变它在 /nix/store 中的路径,而通过 /nix/store 的路径可以准确地引用一个确定的版本。
不过,你既然都可以接受自己打包了,传统包管理器改包改个路径理论上也是可行的,但 Debian 系的打包确实比较复杂,你可能只是想要个比较容易打包的包管理器
或者是让包管理器断开一些依赖。。。

软件依赖的本质是脱离了软件开发者的预想使用环境,或者脱离发行版供应商维护的使用环境,而发生的用户特定的使用环境需求,官方源的安装不存在依赖不支持情况,非官方源安装软件,要么你取得软件开发者的支持(去项目开发社区提需求,开发者想帮你是有办法的)、要么你取得发行版供应商支持(去发行版社区反馈),这种情况依赖有机会解决,如果你是自己打包或不知来源的包,你需要清楚这是非支持范围之外的,需要自己有一定解决能力。
或者是让包管理器断开一些依赖。。。

包管理器的一个重要作用就是正确地获取依赖。如果单纯在打包的时候去掉一个依赖就能跑了,多半是这个包打得有问题
包管理器的一个重要作用就是正确地获取依赖。如果单纯在打包的时候去掉一个依赖就能跑了,多半是这个包打得有问题
找你这个说法。。。opensuse软件库里面所以软件打包都有问题
依赖冲突的本质是不同软件包依赖同一个软件包的不同版本,而被依赖的不同版本的软件包需要将文件装到相同的位置。Nix 彻底解决了这个问题,因为一个软件包的不同版本不会被安装到相同的位置,任何一个微小的改动都会改变它在 /nix/store 中的路径,而通过 /nix/store 的路径可以准确地引用一个确定的版本。
不过,你既然都可以接受自己打包了,传统包管理器改包改个路径理论上也是可行的,但 Debian 系的打包确实比较复杂,你可能只是想要个比较容易打包的包管理器
你需要了解更多,所有linux发行版的lib都是不同版本的文件安装在不同位置的,不是你想象的那样
找你这个说法。。。opensuse软件库里面所以软件打包都有问题
如果你说的是真的,那么也只是更加说明了传统包管理器的依赖管理非常不合理
如果你说的是真的,那么也只是更加说明了传统包管理器的依赖管理非常不合理
现在感觉靠谱的也就是port,portage(这个东西和port有什么区别吗?),nix。。。不过Gentoo源里面软件包是真的少。。。
opensuse用它唯一的理由就是obs,YaST,openqa。。。
nix没有搞懂倒是Gentoo稍稍懂了。。。只可惜感觉太折腾了(尤其是显卡驱动)。。。
如果你说的是真的,那么也只是更加说明了传统包管理器的依赖管理非常不合理
不过我听说在传统包管理器系统上面(除了FreeBSD)编译安装软件只会让系统原来越乱?
依赖冲突的本质是不同软件包依赖同一个软件包的不同版本,而被依赖的不同版本的软件包需要将文件装到相同的位置。Nix 彻底解决了这个问题,因为一个软件包的不同版本不会被安装到相同的位置,任何一个微小的改动都会改变它在 /nix/store 中的路径,而通过 /nix/store 的路径可以准确地引用一个确定的版本。
不过,你既然都可以接受自己打包了,传统包管理器改包改个路径理论上也是可行的,但 Debian 系的打包确实比较复杂,你可能只是想要个比较容易打包的包管理器
确实,只要能简单的正常运行软件,并不在乎背后的逻辑是什么,nix是我之前没了解到的,值得研究一下。
你需要了解更多,所有linux发行版的lib都是不同版本的文件安装在不同位置的,不是你想象的那样
呵呵,很多是区分目录的,不区分目录的so文件是区分不同版本的。
依赖问题不是这些原因引起的,搞清楚为什么会发生依赖。
假设,某个软件fake 1.xx.xx,需要依赖某lib 1.0、1.1、1.2、13.、1.4,与lib < 1.0、>= 2.0冲突
某发行版的V7包含lib 1.0、1.1、1.2、13.、1.4,所以官方源的fake可以运行
过了2年,fake的版本升级到2.xx.xx,需要依赖某lib 2.0、2.1,与lib < 2.0冲突,这时候某用户想在某发行版的V7运行、编译fake的版本2.xx.xx就会出错,这时候有3种情形:1、等发行版的V7升级到V8,以获得支持fake 2.xx.xx;2、去其他已升级fake 2.xx.xx的发行版移植过来,需要同时移植fake 2.xx.xx和lib 2.0或2.1;3、lib 2.xx.xx无法在发行版的V7运行,因为lib 2.xx.xx也有自己的一堆依赖。
所以非官方源永远都会发生依赖问题的,这是软件开发的升级打破了旧的依赖,发行版的依赖与开发者是不同步的,永远会有时间差。
产生依赖问题非常复杂,还有其他情形。
所以玲珑是一个解决方案,玲珑的解决方案是将开发者的软件和环境整体,放在发行版运行。
讨论这些没有意义的,你永远解决不了,永远.......................................
那些吹嘘Nix已解决依赖的人,他从来使用过Nix(哪怕安装来测试一个星期),Nix当然有优点,主要的优点就是隔离的开发环境,类似python的env虚拟环境,好处是同一个软件可以安装不同版本,对普通用户就是随时可以使用最新的版本。
但,Nix社区暂时没有的包,我相信论坛大部分的人自己也弄不出来,说白了就是只能安装Nix官方打包的软件,哈哈,对于普通用户,这与其他发行版只安装官方源没区别(肯定没依赖问题),反而Nix社区的包相对其他发行版少得可怜。
呵呵,我建议去安装Nix用半年,再回来用深度,瞬间幸福感就提升了。
1.只是打包集成了执行文件和库,不动config
2.不是给应用层用的
小白老老实实用应用商店准不出问题,出问题是因为自己装没经过适配的包,control写的依赖不是全都齐全,固有依赖问题。容器化更多的是解决底层依赖版本不匹配的问题,解藕。开发者和维护者写文件和打包的时候不严谨,该出现的冲突问题还是会存在
Popular Events
More

中文 
1.appimage?似乎每次运行都是解压文件到临时目录,这样是不是不能保存软件配置?
2.docker?没用过。
3.snap/flatpack?似乎支持不是太好,而且中文教程太少,想自己打包都难。
4.玲珑?还在测试阶段,支持和教程都不完整。
5.把冲突的依赖放到某一个文件夹下,让软件从指定目录读取以来?不会操作=。=