deb 打包与 rpm 打包孰优孰劣？

haulm

deb 打的包没有烦人的文件依赖问题。

jiangtao9999

deb 也有依赖的问题。

rpm 里，你就是不写依赖，他也会自动加上被依赖的库文件名。

haulm

[quote:f3fdeadef5="jiangtao9999"]
deb 也有依赖的问题。

rpm 里，你就是不写依赖，他也会自动加上被依赖的库文件名。[/quote]

正是如此，所以rpm打包时一些不必要的未知依赖总会让你头痛不已，比如打包一个php，如果我这个PHP包支持两个数据库，那么除非用户装两个数据库，要么就会因依赖问题而无法安装，甚至强制安装都被系统拒绝。所以rpm打包PHP只好把数据库支持和基础包分离，总的来说，rpm包机制不太自由，不易应用。

sejishikong

其实都一样，deb也存为依赖问题的。

Subbo

[quote:4854f773a2="jiangtao9999"]
deb 也有依赖的问题。

rpm 里，你就是不写依赖，他也会自动加上被依赖的库文件名。[/quote]



在spec里面加入“Autoreq : no”就不会记录所需的库。当然，如果没有所需的库，程序还是无法启动的。

haulm

[quote:2d2ad139ca="Subbo"][quote:2d2ad139ca="jiangtao9999"]
deb 也有依赖的问题。

rpm 里，你就是不写依赖，他也会自动加上被依赖的库文件名。[/quote]



在spec里面加入“Autoreq : no”就不会记录所需的库。当然，如果没有所需的库，程序还是无法启动的。[/quote]

谢谢，下次打包PHP我会试试看，很多情况类似于PHP，我们根本不可能要求用户装所有的数据库或者让用户去辨认完整PHP拆散的一堆包，没人有耐心去了解一个软件的所有成分。

jiangtao9999

如果你的 PHP 的附属的功能需要别的库，你强行把他放进去，万一用户是用了需要附加库的代码，将会引起意外，如果这个问题直接导致了服务器程序崩溃退出，你就制造了一个优秀的 DDOS 漏洞。

你这个做法属于强行将一个潜在的本可以避免的系统漏洞放入系统中。
这种做法如果可以，rpm 也不会加入这么无聊的功能。


你可以删掉 libc.so ，来感受一下库文件丢失的快感。

haulm

[quote:642419a5b0="jiangtao9999"]
如果你的 PHP 的附属的功能需要别的库，你强行把他放进去，万一用户是用了需要附加库的代码，将会引起意外，如果这个问题直接导致了服务器程序崩溃退出，你就制造了一个优秀的 DDOS 漏洞。

你这个做法属于强行将一个潜在的本可以避免的系统漏洞放入系统中。
这种做法如果可以，rpm 也不会加入这么无聊的功能。


你可以删掉 libc.so ，来感受一下库文件丢失的快感。 [/quote]

难以理解哦，如果是架服务器就不要用我的包啦，最好自己编译定制，我打PHP包完全是为了学习PHP的朋友。如果是我编译的PHP，肯定是支持主流的三个数据库：mysql、pgsql、sqlite，当系统不存在这三个数据库中的一个时，如果不把PHP包打散编译或者去掉文件依赖时，你想安装PHP包时就会被拒绝，但如果我去掉文件依赖就会导致服务器崩馈么，这就难以理解了，让PHP支持多数据库会因用户没有安装某个数据库而变成有罪了。

假如我安装了一个PHP，在WIN上只要安装一次PHP，debian也是一次，为什么rh系的非要写一个复杂难懂的spec档，拆散成N个包，包之间的依赖是为了解决安装问题的，而不是用来束缚应用的。

PHP程序本身就不是前台脚本，DDOS攻击从何谈起，而PHP在调用数据库时连接失败会导致APACHE崩馈么，我是认为不大可能，如果能的话也请试验了再说。

sejishikong

这种情况无论是deb还是rpm，最好分包，不然的话很容易带来各种问题的。

KDE

haulm 身为版主还说出这么一堆无知的话实在令人遗憾。
1、任何打包技术都不可避免依赖问题，slackware 的包什么也不校验，比 deb 打包岂不更简单？deb 实际校验工作是通过 apt 系统完成的。正因为 deb 没有包含依赖包的信息，所以很多书籍明确表示不推荐使用 deb。
2、你可以不检验依赖关系，rpm 同样有这种机制，你再看一遍面向初学者的《rpm 建包原理》。但是最终能否运行取决于用户的环境和打包者的是否一致，不一致就可能崩溃或者不正常，任何包都一样，除非彻底静态编译。
3、简洁也就不可避免地意味着功能少。开发者偷了懒，就会把烦恼丢给终端用户。作为一个软件/系统开发者，应该把一切方便留给用户，把一切困难留给自己。当然，方便性和灵活性往往又存在一种博弈。
4、你若不想让自己的包依赖某个包，最好的办法是使用 configure 参数禁用对某个包的依赖，或者从系统里卸载那个包，前提是你的系统不会崩溃、你的软件还能够通过编译，否则你就要给软件打补丁。
5、服务器软件分包的原则和桌面软件截然不同，你拿桌面软件的分包原则套用服务器软件当然是错误的。具体原因我过去曾经谈到过，不想重复。

haulm

呵呵，敢于说无知的话才能了解不同的声音。很多东西需要尝试和试验才能定论，如 rpm包也有注明nodep的。个人认为包依赖在于建立一个完整的核心体系，而系统枝叶部份的依赖不能太多，否则就会出现各种怪现象。Everest0.2的工具盘内有不少这种现象，qt4的包群完全牵扯依赖在一起，各个Qt4的功能包的debug部份和release部份也依赖在一起，gimp驴头不对马嘴地和openoffice相互依赖.....，所以rpm的auto-dep是很弱智的。

在spec里面加入“Autoreq : no”就不会自动记录所需的库，但我们在写spec档时可以手工添加依赖。我百分百相信电脑智能化的东西不可能总是能创造出符合应用的东西来。Subbo的帮助正是我最需要的，所以这里谢过Subbo。

最早我学习rpm打包时是苦恼的，因为我不知道Autoreq : no这个知识点，如果我编译的包能得到本发行版大多数用户的应用，就必需保证自己的系统不能迟于更新又不能积极更新。

不想让自己的包依赖某个包，最好的办法是使用 configure 参数禁用对某个包的依赖，或者从系统里卸载那个包，前提是你的系统不会崩溃、你的软件还能够通过编译，否则你就要给软件打补丁。

我想KDE一定是误解我的意思了，在编译一个安装包时，首先要考虑的就是我编译的这个包将提供什么样的服务，这个包在安装后需要什么样的运行环境，需要什么样的功能，然后依照功能我去实现编译前的运行环境，并把现有的运行环境最基础的部份体现在spec档中。正如前面所说，我为了编译完整的PHP，我会安装三个数据库，但我的用户可不会同时安装三个数据库，这时我有必要把数据库的某个文件做为安装PHP的依赖么？这么做，只会强迫我的用户安装PHP前安装三个数据库。如果我把PHP拆散成基础包和三个数据库支持包，当然可行，但编译者首先要对PHP各功能文件有很清楚的认识，准确的说只有开发者最清楚如何分割打包自己的软件。很多软件源码包都有提供合理的spec档，但并非所有的软件开发者都有这个做法。

依赖是用来解释环境的，不是用来约束行为的。

至于服务器，我只是说学习服务器编程的朋友很多，他们如果关心服务器的架设，会用源码去学习编译，根本不可能会去使用这种部份nodep的包。

我希望MGC会有服务器版本，到时讨论这些会很弱智，因为服务器的各包肯定是定制和紧密依赖的。

jiangtao9999

如果你真的想这么写 RPM ，那么你需要给 PHP 添加代码，自动检测当前的系统是否包含你的功能所需要的库文件，不然你就需要你的用户具有和你相同水平的能力，一个初级的用户，你怎么保证他不会突然的使用到别的数据库程序？

要知道现在有些 PHP 代码是支持多种数据库的。你怎么保证这些代码绝对不会使用没有被数据库的库文件依赖的功能？同时，你怎么保证所丢失的数据库库文件仅仅会导致在使用数据库函数的时候才会被调用？

有的程序会把他所有的 .so 文件全部读到内存，只要有一个 so 没有找到被依赖的 so，就会导致崩溃。
你怎么保证没有满足依赖的库文件不会被读入内存？

PS：PHP 的 conf 文件里有选择性的启动功能模块的功能，你应该从这礼下手，而不是 rpm 。但你需要一个自动识别的代码。

haulm

嗯，受教，昨晚打包了Qt4，只是是为everest编译的，之后我将把源码安装包上传到公社自己的存放区中。RPM打包的确比deb有某些应用上的优点，但对打包者增加了不少难度，不合格的RPM包表现为依赖混乱、依赖串岗，所以必要时取消打包时的自动依赖设置也是必需的，某些依赖是完全没有必要的。

对于你说的PHP代码会因缺少数据库导致一些不利因素我是不能苟同的，因为我们经常忘了开启数据库服务就运行了PHP代码，并非如你所述的那么危险。我曾经重新打包过Qt3.3，增加了sql插件，并且将sql插件用另外压缩的方式存储，我也在没有安装任何数据库的前提下，运行了我在有数据库时编译的一个连接数据库的Qt程序，也未象你们所述的如何的不可收拾，有时过份沉泥于某个公式是不可取的。WIN下面有很多的类库，他们之间并不似Linux的RPM机制这么烦琐，Linux的依赖一在于节约空间，二在于保证系统的完整性，原因是Linux有着很强的自由度，使用大量的依赖保证了Linux的完整性，但如果枝叶部份也强调依赖会束缚应用的灵活性，增加应用负担，有个很反面的教材出现在ubuntu，他们不使用ROOT帐户，因此用户每天要做的10%以上的工作是输入密码，所以我对ubuntu没有任何好感，ubuntu的开发者简直把用户当傻瓜。我个人认为，依赖的目的为的是安装的需要、为的是空间的压缩和系统的完整，但不是绊脚石。RPM包机制所生产的包有时太细化了，对于大型软件只会让用户搞不清他们要的是什么。

当然我已经改变主意会去拆散PHP包了，显然我把服务器包做为应用枝叶部份是不合理的，只是我个人偷懒了，而且我打包PHP的确不是为做服务器而工作的，而只是为了类似于桌面应用的角度去学习PHP，甚至在本机上架个服务器也只为了运行一个浏览人是自己的WEB笔记。

haulm

算了，收回的我话吧，现在思想混乱了，RPM打包怎么样依赖就怎么做吧。。。   

sejishikong

像你举的例子，虽然不会如何如何，但是如果没有任何数据库，你那个程序又要用到数据库的话，显然程序运行会出错，如果你不给依赖，那么对于不熟悉的人来说，就很难找到出错的原因，或者能找到，那样其实还是得加依赖。deb也可以写依赖关系，而且应该更详细才对，为什么总说deb不用写依赖呢。你可以拿一个进入debian官方的包看看里面的control文件。
rpm包，除非autroreq有问题，才需要autoreq:no，比如我打的qsopcast，autoreq的依赖就不对了，可能和sp-sc有关，这样才autoreq:no，但在这种情况下，需要的依赖一定要手工加上。