从宏观上来说，linux操作系统（只看OS层面，不谈硬件）就是由静态的文件系统和动态的进程组成的(不知道这样说合适不合适)。文件系统记录了 ”我是什么样的，我有什么“，而进程则能够用文件系统的这些功能动态的改变OS的状态或者对外提供服务。
其实这样的OS也就能够运行了，为什么还要出现软件包呢？大概是人们为了方便的管理操作系统吧，就跟一个国家都是零散的百姓而没有组织机构一样，那样会很难于管理，为此才把地方划为郡县，省市，县，乡，村，甚至大队~~。理想状况下，这样任意一个人需要服务，都可以直接找自己归属的组织去寻求帮助。工作起来效率提高。
操作系统当然不能够只是零散的文件组成，也需要对这些文件/程序进行管理，因此，就有了软件包的概念。某些文件属于某个软件包，某个软件包有某些文件。这样的有序性
是提供了管理效率，但是也是有付出的，那就是存储，需要有额外的空间来记录文件和包的对应关系。当然，在一个包内部，这是不需要的，因为任何咚咚都属于所在的这个包，当环境转移到OS层面之后，多个软件包要在OS上共存，有序管理，我们不仅要记录文件到包的关系，有时也要记录包和包之间的关系。
逐渐的，当这些信息被梳理并且记录时，就形成了软件包数据库的概念。对 RPM 而言就是 RPM数据库。

以前没有包的概念时，是人类直接通过工具操作文件，现在介入了数据库的操作。简单画了个图,表达此改变，如下:

（1）关于 linux 主机上的 RPM 数据库

RPM 在 linux 机器上工作原来是比较明确的，首先有实际的rpm解压缩并且安装后的文件；另外有Rpm 的DB文件，
存储这些安装了的 rpm 的信息，这些库中信息在 RPM进行安装，升级和卸载时进行更新。

RPM命令对两者的操作有： (1):对DB库进行增删查该 (2):对文件系统进行增加和删除和读取。
结合起来看:

(1): RPM的安装/升级，写入DB库，写文件系统，生成安装列表和服务，配置等，执行安装时脚本。
(2): RPM卸载，删除DB库，删除文件系统中归属于该软件包的文件，执行卸载时脚本。
(3): RPM查询, 读取DB库/文件并且显示。

RPM 的在主机上的数据库有好多个，根据不同的应用类型，采用不同的访问方法，可以看下: file /var/lib/rpm/* | grep Berkeley

复制代码能够看到，主要是 HASH 和 BTREE 这两种访问方式。(很奇怪，version 8 的是 HASH, version 9的是BTREE ?是应用相关，还纯粹是作者爱好呢？)

RPM 的所有DB，都是从 /var/lib/rpm/Packages 生成的。可以做个实验，把除了 Packages 以外的其它文件全部删掉。
然后重新 rpm --rebuilddb -vv
这些文件都会一一生成，因为构成这几个新的db文件的信息都在Packages中包含了。(如果你把这个文件干掉了，那就悲催了，
曾经遇到有人把这个文件给删掉了，只好从同组配置接近的机器给他拷贝了一个os和arch一样的机器的Packages，重新生成了下db,还好，能继续用，呵呵)。因为这个文件中记录了你的机器安装的所有RPM和文件列表，一旦这个文件丢失了，rpm就不知道你的机器上有哪些rpm了，当你通过
rpm -qf path 查询某个二进制文件属于哪个rpm时，也不会有结果输出。

关于 /var/lib/rpm/Packages 这个 DB 文件的最初来源，我分析（结合猜测）是这样的:

首先，在安装（或者OS安装时）每一个 rpm 文件的时候，rpm 命令都会把要安装的 rpm 包的信息分析出来，包括我们在第一篇看到的所有TAG还有文件列表等信息；
然后会把这些信息写入 /var/lib/rpm/Packages 文件中，如果这个文件不存在，就创建；当删除包时，就会从 /var/lib/rpm/Packages 中
删除与该包相关的所有信息。该文件中记录了所有 rpm 的全量信息，因此，我们通过 rpm 命令查询时，才能够看到那么多灿烂和丰富的信息。

以rpm -qf 和 rpm -ql 为例：
比如，为了能从 xshell 拷贝文件到windows机器，我经常会用 sz/rz命令，但是有些机器上就是没这个命令，
要安装，又不知道它在哪个包，怎么办，这时就需要用 rpm -qf 来查询了:

找一台安装了 sz/rz 命令的机器: # which sz

复制代码喔，我们发现sz和rz是在 lrzsz 这个包中的，然后在需要的机器上 rpm/yum 安装 lrzsz 包即可。

那么，rpm -qf 命令路径 就能查到这个命令属于那个包，这是怎么做到的呢？

首先我们知道安装 lrzsz 时 rpm 会把 这个包的所有信息写入 /var/lib/rpm/Packages 文件，这个包包含的文件列表也会写入
到 这个文件中，然后才会更新生成 /var/lib/rpm 中的其它DB文件(个人理解，其它DB文件就是为了查询加速而用生成的cache.)

然后，当执行 rpm -qf /usr/bin/sz
复制代码时，rpm 就会去 /var/lib/rpm/Packages 中(或者其它cache文件中)查询包含 /usr/bin/sz 这个路径的
包，当然就查到了是 lrzsz.

有人说，可能查到多个包么？这个是不可能的，因为 rpm 在安装 rpm 文件的时候，也就是往 /var/lib/rpm/Packages
中写数据的时候，会检查这个rpm 中包含的文件列表是否已经在本机安装的其它包中出现了，如果找到了，就会警告: 这个文件和其它某个包中的
某某文件冲突了的错误信息，这个现象做SA的同学应该都见过。

实验: ls -alt /var/lib/rpm/Packages

复制代码我们能够看到，这个文件只对root 可以写，我们尝试改下它的属性: chattr +i /var/lib/rpm/Packages
复制代码设置不可改变属性，然后尝试安装包: rpm -ivh RPMS/i386/test-baby-1.1-1.i386.rpm

复制代码因为rpm 没有权限去写 Packages 这个数据库文件。 # chattr -i /var/lib/rpm/Packages

复制代码这下就成功了，再次验证了 rpm 在包安装时对 /var/lib/rpm/Packages 的写操作确实是存在的。
同样，你也可以同样方法测试下卸载包时对 /var/lib/rpm/Packages 文件的写操作是否存

复制代码/etc/cron.daily/rpm 是 rpm 这个包带的一个每日执行的crontab任务。
/etc/crontab 中配置每天4:02执行 cron.daily 里面的计划任务。
看下这个脚本的内容: cat /etc/cron.daily/rpm

复制代码就是把 系统上所有 rpm 的列表导出下，排序存储在 /var/log/rpmpkgs 这个文件中。
这个文件有什么作用呢？个人分析应该有以下两个作用:

(1): 可以作为rpm -qa 的 cache文件，如果这个文件在很短时间内刚更新，rpm -qa 直接打印该文件内容即可。
(2): 有人可能已经想到了，它可以帮助恢复你的rpm 数据库文件，如果你不小心把 /var/lib/rpm/Packages 弄坏或者丢了，
但是很幸运，var/log/rpmpkgs 这个文件还在，而且是比较新的，然后你就可以如下恢复你的rpm 数据库了。

第一: 找到 系统的安装镜像包，也就是包含了所有OS的RPM列表。
第二：写个脚本，读取 var/log/rpmpkgs 文件，每行是一个rpm 文件，进行安装，这里的安装可不是实际安装。而是
要采用一个特殊的功能，看下 rpm 的 man 手册： --justdb

复制代码只是更新rpm 的数据库，并不更新系统文件（好像这个安装过程也是 --noscripts的，如果你真的走到这一步，可以检验下，然后告诉我，呵呵）。

2012-12-30 12:13 上传 下载附件 (719.82 KB)

简单描述一下一个 rpm 从发布进 yum， 到客户端可用的过程:

yum 中 rpm 从发布到可用的过程

1. 开发完成，RPM 已经通过 rpmbuild 或者其它工具制作好，把 rpm 放到 yum 服务器的 rpm 仓库目录下 。
2. 在 yum服务器的 仓库目录 (具体目录位置后面会讲)执行 createrepo 命令，该命令会扫描当前目录(包括子目录)里面的rpm 文件，记录rpm 文件的信息，写入repodata 目录中的索引文件中。这样 yum 中就有了新发布的 rpm 的信息了。
3. 使用者在客户端安装了 yum 命令，通过配置 yum 的客户端配置文件，指定了一个或者若干个安装源， yum 安装/检索包时会去这些安装源上检索索引文件。
4. 使用者在客户端使用 yum install pkgname 方式安装包，yum命令 会把配文件中配置的 yum服务器的地址（安装源）作为目标服务器，通过http/ftp/file服务去 yum 服务器上下载索引文件，然后在索引文件中查找有无指定的rpm(适合在本系统安装)，找到的话，就按照配置中的路径组成url地址，下载rpm, 并且在本地安装。
5. 安装后，索引文件和rpm包会cache到本地的cache目录，方便下次使用，而且把安装rpm 的信息记录进本地 rpm 的数据库文件中。

为了读者能够实际操作一把，我们给出一个实际的例子: