本帖最后由 wvb 于 2020-5-9 10:54 编辑

这个想法其实很简单，也许本身已经在实现或者已经实现，我也不知道，说出来大家聊聊看。。。。


debian包管理有个问题，就是依赖矛盾导致很多软件无法更新或者安装。例如：A和C软件依赖libX1.8 B和D软件依赖libX1.9 安装了A和C，B和D不能安装，安装了B和D，A和C不能安装

而用flatpak也有一堆问题，体积庞大、安装慢、运行慢等等。。。安装了A、B、C、D的话libX1.8、libX1.9就分别安装了两遍。。。


QT是可以安装多个版本的，但是不同的是，不同版本的qt就像两个软件一样，qt5 qt4 qt3,而不是qt就是同一个软件，然后多版本根据需要存在
debian的好处是包尽量不冗余

那么我们是不是可以在debian包管理的基础上改进版本依赖的管理，同时允许一个库的多个版本存在，但是不是像Qt那样像是两个软件一样，依赖的时候各取所需，当上层软件都升级后再自动清除老版本的库？

安装A 自动安装了libX1.8 安装B，自动安装了libX1.9
安装C的时候libX1.8已经安装，就不用冗余安装，安装D的时候libX1.9已经安装，就不用冗余安装
卸载的时候A、C都卸载后才自动卸载libX1.8  B、D都卸载后才自动卸载libX1.9

看上去和qt多版本有点像，不过不同的是他是本身就多版本包容的，而不是Qt像一样，每个版本像不同的软件一样，例如Qt5的5.2.1个5.2.2就又矛盾不能同时存在

改进使得包管理更加包容和智能
主要改变的是包的数据库管理和软件运行时调用库的时候怎样自动匹配库
尤其是后面，像是要做比较大的改变，但是我们可以先针对桌面应用，在desktop文件上做文章，或者直接改变应用调用库文件的机制

这个改变可以作为deb包管理的一个特性，可以不开启或者开启，不开启的好处是系统冗余少，同时安装的库版本少，系统稳定性安全性应该更好，开启的好处软件兼容性好，但是不会像flatpak或者snap或者APPimage那样重复打包依赖的库文件