RPM 包的依赖关系说起来是简单的因为它所谓的依赖关系仅仅是一个个简单的如“要安装 A，需要提前准备好 a1,a2,a3”这样的条件。我们在安装前可以通过一个简单的 rpm 命令来查询一个包的依赖关系。
# rpm -q --requires -p wireshark-1.2.2-1.fc12.i686.rpm
/sbin/ldconfig
config(wireshark) = 1.2.2-1.fc12
libc.so.6
...
libcom_err.so.2
...
libpcap.so.1
...
libsmi.so.2
...
python(abi) = 2.6
...
RPM 的依赖性同时又是繁琐的，因为它的依赖关系里只包含了 A 需要 a1,a2 和 a3 的信息，并没有包含 a1,a2 和 a3 是由哪个包来提供。对于如 python 这样直接给出依赖包名，我们可以轻松地找到 python-xxx.rpm；对于如 libpcap.so.1 这样熟悉的库，我们知道它对应 libpcap-xxx.rpm；对于一部分不熟悉的，如 libsmi.so.2 这样的依赖库，我们也可以找到恰好与该库同名的 libsmi-xxx.rpm。但是对于 libglib-2.0.so.0 这样的库，你会很容易“猜”出它是来自于 glib2 软件包的吗？正是因为这样的喋喋不休，以及对应依赖包的含糊性，使得用户对 RPM 的依赖性产生了一定的畏惧心理。
那么怎么确定一个库由哪个包提供呢？对于已安装的包，可以用通过下面的方式来查询：
# rpm -q --whatprovides libpcap.so.1
libpcap-1.0.0-4.20090922gite154e2.fc12.i686
但是对于在安装过程中存在依赖的库，显示这种方法是不可行的。在一台独立的系统里，这个答案甚至是无解的。某个库包含在哪里，只能遍历安装包，在每个包查询“我提供了哪些东西”的才能找到。
下面是通过安装盘中找 libglib-2.0.so.0 由哪个包提供的例子，用时 21 秒，着实不短。如果用这种方法查找 libz.so.1，需要数分钟才能完成。
# mount /dev/hdc /mnt/cdrom
mount: block device /dev/hdc is write-protected,mounting read-only
# cd /mnt/cdrom/Server
# time for i in `ls -1`;
do
if rpm -q --provides -p $i | grep -q libglib-2.0.so.0
then
echo $i
break
fi
done
glib2-2.22.2-2.fc12.i686.rpm
real 0m21.804s
user 0m3.946s
sys 0m14.396s
yum 对 RPM 包的处理是一个典型的“空间换时间”过程。通过对源中所有 RPM 包的预处理，生成所有安装包关于包含文件，依赖，冲突等信息的索引，并且以 sqlite 格式存放在 /var/cache/yum 对应目录下面。
基于 yum 索引查找 libglib-2.0.so.0 由哪个包提供的例子如下：
# time echo "select packages.name from packages inner join provides
#on packages.pkgKey = provides.pkgKey where provides.name = 'libglib-2.0.so.0';" |
#sqlite3 /var/cache/yum/i386/12/dvd/primary.sqlite glib2
real 0m0.008s
user 0m0.003s
sys 0m0.005s
同样的查询，用索引数据来处理，只需要约 1/100 秒。数十兆的空间，换来的是成百上千倍时间效率的提升。
多年来，RPM 关于依赖性的原理并没有大的变化，只是经由这么一包装，让大家觉得依赖性逐渐不再是一个大的问题了。
整理自网络
原文链接：https://www.f2er.com/javaschema/284445.html