中文 
wvb
deepin
2020-05-28 00:40 deepin https://bbs.deepin.org/post/193902
操作系统本身解决不了，windows同样存在不兼容老硬件的问题
可能你把我说的问题困难化了。
只要flatpak的能跑起来，那么改进deb机制后，冗余远低于flatpak的，库新旧版本不冲突的也能跑起来的。
Reply Like 0 View the author
#21
可能你把我说的问题困难化了。
只要flatpak的能跑起来，那么改进deb机制后，冗余远低于flatpak的，库新旧版本不冲突的也能跑起来的。
wvb deepin
2020-05-28 00:44 deepin https://bbs.deepin.org/post/193902
操作系统本身解决不了，windows同样存在不兼容老硬件的问题
比如某个驱动依赖libC的3.1版本，但是现在操作系统的libC是3.2版本，然后这个驱动运行不了。但是如果这两个版本的库都同时存在的话那么这个驱动应该就可以运行，操作系统根据需要指引每个软件去调用对应版本的库。
Reply Like 0 View the author
Feng Yu
deepin
2020-05-28 03:16 deepin 本帖最后由 abcfy2 于 2020-5-27 19:20 编辑
你应该把这些话发到Debian官方的英文邮件组去怼一下Debian的社区大神们，你发这里没什么用，只是无病呻吟罢了
建议去给Debian官方提意见去 https://www.debian.org/MailingLists/ 发这没用，什么也解决不了
你应该把这些话发到Debian官方的英文邮件组去怼一下Debian的社区大神们，你发这里没什么用，只是无病呻吟罢了
建议去给Debian官方提意见去 https://www.debian.org/MailingLists/ 发这没用，什么也解决不了
Reply Like 0 View the author
普通石头
deepin
2020-05-28 07:41 deepin https://bbs.deepin.org/post/193902
可能你把我说的问题困难化了。
只要flatpak的能跑起来，那么改进deb机制后，冗余远低于flatpak的，库新 ...
是你把问题想得太简单了，难道只是不同版本的lib共存就能解决所有依赖问题了？flatpak和appimage这些东西的存在也只是在一定程度上缓解依赖问题而已，而且是尽量不影响系统本身。你觉得系统应该要让多少种lib?多少个版本共存？一般的发行版都会支持一些组件多版本共存，但也仅限于部分而已，比如Debian下多个版本的gcc共存很容易，但不可能有哪个发行版会想要共存所有库的不同版本，不说维护的工作量有多大，系统多么冗余，很多东西本身就是互斥的，而且上游不再维护的旧代码难道要打包者去维护吗？安全漏洞不考虑？要扯驱动的话，旧的驱动代码很可能就不兼容新的内核接口，难道还能同时跑几个不同的内核？举个例子，AMD的旧显卡的私有驱动就只支持旧版本的内核和xserver，你觉得要怎么解决？
Reply Like 0 View the author
wvb deepin
2020-05-28 18:47 deepin https://bbs.deepin.org/post/193902
是你把问题想得太简单了，难道只是不同版本的lib共存就能解决所有依赖问题了？flatpak和appimage这些东西 ...
是你把问题复杂化了，我并不是说要用多个lib共享来解决所有问题。
冗余本身就是个问题，谁也不喜欢系统里面同时装一大堆版本不同的同一个库。所以，大家的共同愿望都是减少冗余，用没有漏洞的更好的库。并不是说版本共存的多是多么好的好事，明白吗? 我从来都不认为多个版本多多的是好事。
但是，我们要面对现实的是在我们去冗余的过程中难免会面对新旧版本库冲突的问题，这个时候可能也就是前后两个版本而已，不是每个软件都会在库更新后跟着及时更新的，这个时候冗余是现实需要，明白吗？
flatpak和appimage本身就是在解决这个问题，当然可能是反过来的，新的app依赖的库比系统本身使用的更加新，这个时候就出现了冲突。所以flatpak和appimage软件自带了库，自带了可能更加新的库，也可能更加老的库，也可能和系统本身就存在的一样版本的库，反正就是不管是新是旧，系统有没有，他都自带了一份，而且每个app都会自己带，就极大可能很多app都带了同样的同版本的库，明白吗?
我说的改进deb的目的是来解决这个问题，明白吗？不是解决你提出来的问题的，明白吗？
Reply Like 0 View the author
wvb deepin
2020-05-28 18:53 deepin https://bbs.deepin.org/post/193902
你应该把这些话发到Debian官方的英文邮件组去怼一下Debian的社区大神们，你发这里没什么用，只是无病呻吟罢 ...
我只是打算把这个问题和建议提给深度，没有打算提给Debian，我不是开发者，我知道实现起来不容易，只是希望懂的人看到能有所启发而已。
请你注意言辞，没有怼谁谁谁，更谈不上去怼什么大神，还有就是“无病呻吟”，你觉得合适？
如果你对这个话题不感兴趣，你可以不搭理这个帖子，而不是说什么“无病呻吟”。
Reply Like 0 View the author
Feng Yu deepin
2020-05-28 19:47 deepin https://bbs.deepin.org/post/193902
我只是打算把这个问题和建议提给深度，没有打算提给Debian，我不是开发者，我知道实现起来不容易，只是希 ...
不说你无病呻吟难道说你“野生产品经理”？你品，你细品，你自己选一个吧
Reply Like 0 View the author
wvb deepin
2020-05-28 23:11 deepin https://bbs.deepin.org/post/193902
不说你无病呻吟难道说你“野生产品经理”？你品，你细品，你自己选一个吧 ...
那你算什么？指点江山的三流评论家？还是除了怼没有实际建树自负狂？你品，你细品，你自己选一个吧
Reply Like 0 View the author
wvb deepin
2020-05-28 23:13 deepin https://bbs.deepin.org/post/193902
不说你无病呻吟难道说你“野生产品经理”？你品，你细品，你自己选一个吧 ...
如果你对这个话题不感兴趣，你可以不搭理这个帖子
但是，你继续不擦屁股就出来撒野，那我也没有好言奉陪。
Reply Like 0 View the author
普通石头 deepin
2020-05-29 16:35 deepin https://bbs.deepin.org/post/193902
是你把问题复杂化了，我并不是说要用多个lib共享来解决所有问题。
冗余本身就是个问题，谁也不喜欢系统里 ...
懒得和你多说了，你自己不明白，硬要以为自已比谁都明白，真当Debian的维护者是傻子了
Reply Like 0 View the author
wvb deepin
2020-05-29 17:29 deepin https://bbs.deepin.org/post/193902
懒得和你多说了，你自己不明白，硬要以为自已比谁都明白，真当Debian的维护者是傻子了 ...
好吧，都是大神，自己加的戏还要给别人扣帽子
Reply Like 0 View the author
oucaijun
deepin
2020-09-28 21:05 deepin 任何新的建议都可能是让开发者挠头，但这确实是个好的建议，能解决很多人的痛点。如果不满可以以理服人。
Reply Like 0 View the author
SamLukeYes deepin
2020-09-28 21:17 deepin nix 了解一下。虽然我没用过，但论坛里有大佬用 nix 成功地在 deepin 上运行了 megasync
Reply Like 0 View the author
Comments
399913628
2020-10-13 23:33新槽点，去玩一下。谢谢。
wvb deepin
2020-10-13 19:23 deepin https://bbs.deepin.org/post/193902
任何新的建议都可能是让开发者挠头，但这确实是个好的建议，能解决很多人的痛点。如果不满可以以理服人。 ...
好久没有登录论坛了，以为这个帖子完全沉了，感谢支持。
Reply Like 0 View the author
neko
2020-10-13 21:05 Moderator
nix完事
Reply Like 0 View the author
dororo2020 deepin
2020-10-13 21:50 deepin 希望那些在deepin用nix成功的大神多科普科普如何使用，网上中文教程几乎没有，冷门到尴尬
Reply Like 0 View the author
wvb deepin
2020-10-14 01:43 deepin https://bbs.deepin.org/post/193902
nix 了解一下。虽然我没用过，但论坛里有大佬用 nix 成功地在 deepin 上运行了 megasync ...
专门了解了一下，nix的理念确实和我说的想法是一样的。deepin出个nix版本的也不错。
Reply Like 0 View the author
lookfor
deepin
2020-10-14 02:30 deepin https://bbs.deepin.org/post/193902
希望那些在deepin用nix成功的大神多科普科普如何使用，网上中文教程几乎没有，冷门到尴尬 ...
论坛搜索 nix
Reply Like 0 View the author
wvb deepin
2020-10-14 17:10 deepin https://bbs.deepin.org/post/193902
希望那些在deepin用nix成功的大神多科普科普如何使用，网上中文教程几乎没有，冷门到尴尬 ...
nix的理念deepin的大佬们确实可以考察然后吸收一下
Reply Like 0 View the author
wvb deepin
2020-10-14 17:12 deepin https://bbs.deepin.org/post/193902
论坛搜索 nix
有是有，相对来说确实是有些冷门
Reply Like 0 View the author
Please sign in first
Rankings
- 7 days
- 30 days
- 90 days
Popular Events
More
这个想法其实很简单，也许本身已经在实现或者已经实现，我也不知道，说出来大家聊聊看。。。。
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那样重复打包依赖的库文件