一个改进debian包管理的建议,体积上折中flatpak和deb
Tofloor
poster avatar
wvb
deepin
2020-05-09 18:30
Author
本帖最后由 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那样重复打包依赖的库文件
Reply Favorite View the author
All Replies
1 / 3
To page
wvb
deepin
2020-05-15 22:11
#1
完全沉了
Reply View the author
jerry979
deepin
2020-05-15 22:25
#2
说起来容易,俺也不是学这个的,俺也不知道能不能实现
Reply View the author
herdde
deepin
2020-05-15 22:27
#3
你需要 gentoo
Reply View the author
enforcee
deepin
2020-05-15 22:28
#4
主要问题不在于包的版本
而是包中的文件

包互相冲突实质上是这两个包提供了相同位置的同名文件 因此不能同时安装两个
而flatpak不同版本是隔离开的 没有这个问题
Reply View the author
coslyk
deepin
2020-05-16 00:22
#5
Deb本身就支持这个功能,只是一般软件仓库里只提供libX的一个版本,下载网上的deb包可能就会出现问题。

如果libX向后兼容的话,依赖于libX1.8的包同样可以使用libX1.9的。
Reply View the author
wvb
deepin
2020-05-21 00:50
#6
https://bbs.deepin.org/post/193902
主要问题不在于包的版本
而是包中的文件

其实应该让包管理器管理安装后的文件位置,而不是包本身管理文件位置,这样就可以多个版本的依赖共存了,兼容性也就好很多了。不知道这样的包管理器有没有?
Reply View the author
wvb
deepin
2020-05-21 00:56
#7
https://bbs.deepin.org/post/193902
Deb本身就支持这个功能,只是一般软件仓库里只提供libX的一个版本,下载网上的deb包可能就会出现问题。

如 ...

本身支持吗?像Qt版本一样那种吗?那个不算是兼容啊,解决不了很多现有冲突。。。。 有很多软件更新的困难就是依赖冲突问题。。。。。
Reply View the author
wvb
deepin
2020-05-21 00:57
#8

gentoo有这个功能?我研究一下,如果gentoo的包管理好用,deepin可以考虑拿过来试试
Reply View the author
wvb
deepin
2020-05-21 01:04
#9

大致了解了一下,gentoo太极客了,做不到开箱即用,估计很多人玩不转,还是算了。。。。。。。
Reply View the author
ghostry
deepin
2020-05-21 01:10
#10
flatpak不是有runtime吗?
Reply View the author
wvb
deepin
2020-05-21 01:20
#11
https://bbs.deepin.org/post/193902
flatpak不是有runtime吗?

flatpak包太臃肿啊,启动还慢
Reply View the author
wvb
deepin
2020-05-21 23:40
#12
看到论坛里面说的 , 换个源换着换着就只能重装系统了,恐怕也和这个缺陷有关,所以这个帖子还是有参考价值,希望专业的人能看到。。。。。。。。
Reply View the author
enforcee
deepin
2020-05-22 00:34
#13
本帖最后由 enforcee 于 2020-10-13 16:48 编辑
https://bbs.deepin.org/post/193902
flatpak包太臃肿啊,启动还慢

我觉得flatpak和windows的模式很接近
就是把依赖统一起来大家都只用一个(GNOME或KDE等)
如果所有应用程序都安装flatpak版本的就不显得大 (目前我知道一个Endless OS是flatpak主导的 还有个Nitrux是用appimage)
但是问题现阶段主流发行版都不是纯用flatpak 导致问题就是同样的依赖系统自带一份 flatpak又带一份(如果还用snap appimage就又多好几份)
#还有问题是flatpak似乎不会自动卸载旧版本的runtime 经常用的话要手动管理下 更新一次有可能好几个GB就付之东流啦

(2020年10月13日)

既然帖子浮起来了就更正一下
flatpak清理不需要软件包的命令
flatpak remove --unused

flatpak还应用了原子更新 相比于传统的软件管理每次更新都要下载完整包 flatpak只需要下载一小片“补丁”就能完成更新

导出flatpak软件包参见 https://bbs.deepin.org/post/203551

总体来说flatpak“新一代软件管理”还是实至名归的

Reply View the author
wvb
deepin
2020-05-22 02:07
#14
https://bbs.deepin.org/post/193902
我觉得flatpak和windows的模式很接近
就是把依赖统一起来大家都只用一个(GNOME或KDE等)
如果所有应用程序 ...

几乎很难大家都都统一一个runtime,就算是是统一到一个品牌的runtime还涉及版本更新的问题,Ubuntu就可能得好几个共存,因为软件本身可能更新不够及时。就算统一到同一个rutime的同一个版本,大家依赖的库还是会有很多冗余,系统体积超级庞大,并不好。
Reply View the author
enforcee
deepin
2020-05-22 08:25
#15
https://bbs.deepin.org/post/193902
几乎很难大家都都统一一个runtime,就算是是统一到一个品牌的runtime还涉及版本更新的问题,Ubuntu就可能 ...

所以还是社区内部混战的原因
最好的解决方案还是专心一种包管理 要么原生的要么全flatpak/snap
deepin目前的解决方案(应用商店)是在原生包管理加了个自己的源 安装软件是方在外部目录里的 应该是避免了一些原来包管理的弊端
Reply View the author
wvb
deepin
2020-05-22 17:06
#16
https://bbs.deepin.org/post/193902
所以还是社区内部混战的原因
最好的解决方案还是专心一种包管理 要么原生的要么全flatpak/snap
deepin目 ...

嗯嗯,这样挺好,但是deepin就是有个软件更新不及时的问题,还有就是部分更新频率低又不开源的软件依赖的库比较老,也会有兼容性问题。
Reply View the author
wvb
deepin
2020-05-22 17:08
#17
https://bbs.deepin.org/post/193902
所以还是社区内部混战的原因
最好的解决方案还是专心一种包管理 要么原生的要么全flatpak/snap
deepin目 ...

我提的这个思路就可以解决这个兼容性问题,还能尽可能避免冗余
Reply View the author
leafgreen
deepin
2020-05-22 17:58
#18
我认为一个工具是没办法的解决所有需求的,做不同的工具做不同的事情才对。flatpak,snap 和 appimage就是为了解决依赖问题出现的,冗余是必然的。你想不冗余的话就先使用apt,不行就用flatpak,snap 和 appimage。不过你这个想法也挺有意思的,不妨自己创造一个版管理器。
Reply View the author
wvb
deepin
2020-05-26 02:03
#19
https://bbs.deepin.org/post/193902
我认为一个工具是没办法的解决所有需求的,做不同的工具做不同的事情才对。flatpak,snap 和 appimage就是为 ...

哎,可惜我自己不是程序员,代码也就写个helloworld的水平。。。。

我觉得操作系统通过某种机制是可以解决这个问题的,不过要有人来做。deepin团队可以考虑做一下这个。然后从用户层面来看原来的使用没有什么改变,只不过安装软件的时候冲突更少了。

比如某个打印机闭源驱动,更新频率很低,也不及时,支持的libC的版本假设比较老,然后,系统就会出现系统更新后打印机不可用的问题,很让人头疼。。。。。。。
Reply View the author
普通石头
deepin
2020-05-26 19:02
#20
https://bbs.deepin.org/post/193902
哎,可惜我自己不是程序员,代码也就写个helloworld的水平。。。。

我觉得操作系统通过某种机制是可以解 ...

操作系统本身解决不了,windows同样存在不兼容老硬件的问题
Reply View the author
1 / 3
To page