rpm 建包原理(2010.11.22 更新)

KDE

[quote:32b0d82c16="wjping119"]我就觉得rpm包不如tgz包好用．看看有多麻烦！！！[/quote]
如果你是指开发者，那是因为你习惯了不为用户考虑软件包依赖关系和用户易用性这种偷懒的做法。如果你的开发环境具有别人没有的软件包，别人是猜不出来你的软件包到底依赖什么的，要使你的包运行起来，简直是一场噩梦。开发者偷懒，就意味着普通用户无穷无尽的麻烦。不要把普通用户当成高手或者系统管理员。
如果你是指普通用户，那就丝毫道理也没有。开发者尽量把一切问题都预先考虑进去，自然会带给普通用户舒适。如果说 rpm 不如 win 下的安装程序简单易用，倒还情有可原，毕竟使用 rpm 还需要手工输入命令行。
对于用户而言，deb 和 rpm 都有很好的工具解决依赖关系，前提是开发者预先精心做好软件包。这其实是开发者的本分。

asmcat2000

不错，解决了对RPM认识的细节问题，问一下：已安装的RPM包总 数据库在/etc下哪个文件？

KanKer

/var/lib/rpm/下面。

suowei1979

good

yongq

[quote:ac4d017423="Fujinsan"]rpm的机理确实比tgz复杂一些，但对于用户则更简易一些。

其实目前存在的几种软件包格式都有一定的不足：
1、tarball格式对于开发者来说比较容易理解，只要按照规范，做起来也容易，但对于用户来说却并不是最简单的；
2、rpm和deb都功能强大，deb在解决倚赖性方面甚至更胜一筹，但制作起来都比较麻烦，对于用户也不是完全那么简易的。[/quote]
deb 的制作比 rpm 复杂很多, rpm 只要编辑一个 .spec 文件就可以了, deb 则是把相应的文件放在一个叫 debian 的目录下. rpm 的 source package 就一个 .src.rpm 文件, 而 deb 的 source package 通常会包含很多文件. 这两方面的比较使得 rpm 和 deb 从表面上就显得风格迥异.

这些差异的出现或许有其偶然因素, 不过应该都有各自的理由, 我本来也嫌 deb 的 source package 包含太多的文件而感到不可思议:"搞这么多文件, 别人复制起来可真是麻烦!", 但事实并非我原先想象的那么简单, Debian 的开发者分布于全球各处, 合计有上千人, 他们都需要把制作好的 source 和 binary 包送到 Debian 的那一两台 server 上, 有些人的网速很慢, 传一次不容易, 如果你每次为一个小修改而上传整个 source 包就很浪费事件了, 这样 deb 的 source package 就会以一个 .orig.tar.gz 和 一些 patch 的形式出现, 当每次 revision 后只要把 patch 部分上传就行了.

再看 deb 的制作, 前面说过 deb 需要写很多个小文件, 不象 rpm 只要写一个 .spec 即可. rpm 格式的 build 基本上由 rpm 这一个程序主导(好像现在又有了 rpmbuild), 而 deb 不同, deb 主要依靠一个名为 rules(由包维护者自己提供) 的可执行文件, 它的参数是一个目标的名字, 比如 build, configure, clean 和 binary 等. 你可能想不到的是: 通常这个 rules 文件是一个 Makefile, deb 通过 make 对目标的依赖性来方便地控制 build 的流程(这给调试节省了宝贵的时间). 而且由于编写这个文件的人是你自己, 所以控制权完全在你自己手里. 在此, rpm 和 deb 的设计体现出很不相同的哲学.

Debian 是一个复杂而严谨的系统, 为了规范设计, Debian 提供了很多 Policy http://www.debian.org/devel/. 我没见过哪个 RPM based 的系统提供这些东西, 当然这跟包格式本身并不相干, 不过在 deb 包在制作出来的时候, 有相关的程序会被调用来检测 deb 包有那些不符合 Policy 之处.

另外, 你要是做过 deb 的话, 会发现 Debian 里有 tons of 相关开发工具, 如果你熟悉了这些工具, 制作 deb 就变得简单多了. 当然, 要做一个高质量的完全符合 Policy 的 deb, 你还需要好好下点工夫. 我想, 其实最对一条对做任何事情都成立.

DOS/Windows下，过去没有统一的软件包格式，一般都是分为压缩包直接拷贝和自行开发安装程序，最后发展出多种安装程序制作工具。微软受到rpm和deb的启发后开发了msi软件包格式，逐渐将以前的安装程序制作工具整合为一种统一的类似rpm的格式，从而使安装包的制作和使用更加简便。

解决软件包问题是Magic Linux推广普及的一个重要关口，解决这个问题只需要做两件事情：
1、开发使软件包制作更加简易的工具。这个工具应解决软件包维护、集成套件打包、自开发软件打包等问题，让即使是初学者、刚加入ML项目的朋友也能够完成软件包的制作工作。
2、开发适用于所有Linux软件包格式的用户工具。将现有的rpm管理工具、deb管理工具、tarball管理工具等软件管理工具集成起来，建立统一的软件包倚赖关系树，同时解决单独的软件包管理工具的缺陷和不足之处。

以上是我的一点拙见，对彻底解决感兴趣的朋友不放尝试一下。

ygw_ycf

http://yynet.w28.west263.cn/dzds/root/shownews1.asp?NewsID=601

KDE

更正了一处重要错误，对不起大家。

chaobill

对于我来说，要安装一个软件，有可能用到的库有三种
系统库，通用库，私有库

对于一个软件的更新，无非是
添加文件，替换文件，删除文件

对于一个软件的卸载
是否删除通用库，是否删除用户资料

/usr/bin 下挤了所有软件是很笨的想法
我曾从a开始运行了几个可执行的文件，好几个都是Demo
一个软件就应该有它的目录

KanKer

如果一个软件就有一个软件的目录，那控制台下的命令自动提示功能就没用了。至于每个软件的私有库本来就是放在其各自目录下的。

碧轩

哈，受益非浅，谢谢了！

baif

搞明白了，是版本控制的一个关键字。

KDE

更新！

jiangtao9999

有没有 if 语句的用法？
以及其他语句的是用方法～～

KDE

[quote:2e4c4d2e92="chaobill"]对于我来说，要安装一个软件，有可能用到的库有三种
系统库，通用库，私有库

对于一个软件的更新，无非是
添加文件，替换文件，删除文件

对于一个软件的卸载
是否删除通用库，是否删除用户资料

/usr/bin 下挤了所有软件是很笨的想法
我曾从a开始运行了几个可执行的文件，好几个都是Demo
一个软件就应该有它的目录[/quote]

典型的 windows 用户后遗症。linux 是一个庞大的多用户、多任务网络操作系统，对于熟悉她的人来说，很多情况下使用控制台会更加高效，特别是没有 x 环境的服务器。要是完全把每个软件都分开存放，将使控制台下强大的自动命令补齐功能失效！否则你必须把所有软件的私有目录加入路径，这是可怕的，不讲操作是否可行，仅仅浪费在搜索路径上的时间就足以使你精神崩溃。

KDE

那些强调开发自有包管理系统的人的人都是典型的程序员脑袋，整天就想着怎么搞出个新玩意来。

开发一个新的包管理系统，对用户而言，就意味着引入了新的不兼容性，因为很可能拿你的包到别的系统里根本不能用，除非你能“通吃”，至少现阶段这是不现实的。标准化的意义何在？对于那些这样做的人，你是否负责任地真正替用户考虑一下？在前人的基础上加以改进才是正确的，即便如此，对原有技术的扩展也必须做到向下兼容，这是为了保护用户既往在这个产品上的经济、智慧和体力上的投资。

对于那些使用古怪包管理工具的发行版，除非拥有庞大的软件包打包队伍，否则会使用户面临软件包匮乏的尴尬局面。这会导致什么后果，你心理清楚。

还是那句话，先进的不一定是好的，也不一定会被接受。市场是检验产品的唯一标准。