- 主题:[转载]容器化打包格式不是 Linux 应用的未来
某些东西依赖phonon4qt5，而这玩意需要有一个backend，它自动选上的
是backend-vlc，然后就依赖vlc了……如果先装backend-null就不会依赖
vlc，当然还有其它的见鬼依赖要解决……
Debian这个发行版的基本理念是可以完全通过二进制安装来搞定一切，
所以打包会有很多复杂的拆分，有互斥特性的就打包成不同的变体，
有动态可加载模块的就拆出模块，遇到实在拆不开的也不方便做变体的，
那就只好多依赖了。
跟Gentoo和Arch的玩法不太一样。基于源码编译（或者二进制/编译混合）
的发行版处理这种问题当然就好做得多。
【 在 ayaka (ayaka) 的大作中提到: 】
: 我觉得这个事你得问debian那个打包的是怎么想的，你想装quassel他就是会给你装vlc，不过有折衷的办法，就是你装一个虚拟的声音服务还是什么的，忘了，反正就挺麻烦
--
FROM 122.233.190.*
从这个图上来看，是libnotify4需要notification-daemon，
然后apt从一堆能provides notification-daemon的包里
选了一个当前系统里“它认为最合理”的cinnamon桌面环境，
然后再引出其它的依赖……自己选一个别的nd也许就没这事了。
这种涉及多选一的问题整体上来讲对于介意依赖膨胀但又
没心思去追踪的人来说是不太好解决-_-;;;;
【 在 ayaka (ayaka) 的大作中提到: 】
: [upload=1][/upload]
--
FROM 122.233.190.*
1. 我的原话可没这么说，所以你反问的目标有点奇怪
2. 依赖问题导致的膨胀有大有小，我指的是对于制作一个
高品质的Linux dist来说，如果想要让依赖问题尽可能少
导致使用不便，那么考察因依赖导致的膨胀这个指标时，
源码编译的发行版的膨胀通常会比完全二进制安装不碰编译
的发行版的膨胀小很多
【 在 pixYY (飞精灵) 的大作中提到: 】
: 基于源码编译难道就没有代码库的依赖问题吗？
--
FROM 122.233.190.*
对对对，在正常情况下看到一些毫无生产环境运维概念的人部署出来的
系统各种不爽，比如用同一个uid既安装程序又交互运行daemon，比如
自编译的东西一堆prefix=/usr/local，另一堆prefix=/usr/local/<name>，
再一堆prefix=/usr/local/<name>-<ver>，再一堆prefix=/opt/<name>……
而且骂好几遍都不听……
扔到docker里爱咋样咋样懒得管了-_-;;;;
【 在 oldwatch (一条叫java的鱼◎城内风光独好) 的大作中提到: 】
: 嗯，无非就是端口，存储，环境变量
: 容器里面哪怕闹翻天都能假装看不见
: 尤其适合有洁癖的……
: ...................
--
FROM 122.225.220.*