RPM 包依赖
来源:互联网 发布:警惕网络陷阱观后感 编辑:程序博客网 时间:2024/05/22 06:28
RPM 的依赖性是个很让人头疼的问题。每次系统安装完成过后,想再装一个软件包,敲下回车之前,都会心惊胆战,生怕跳出个依赖性错误。而在一个依赖性错误的背后,可能还牵连着更多的依赖性。这个问题让很多 Linux 用户望而生畏。
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 关于依赖性的原理并没有大的变化,只是经由这么一包装,让大家觉得依赖性逐渐不再是一个大的问题了。
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 关于依赖性的原理并没有大的变化,只是经由这么一包装,让大家觉得依赖性逐渐不再是一个大的问题了。
整理自网络
0 0
- RPM 包依赖
- Centos rpm包依赖
- rpm包依赖问题解决,几个包相互依赖
- 解决RPM包循环依赖的问题
- rpm包互相依赖 无法安装 死锁
- Oracle依赖包rpm安装检查
- yum下载rpm包以及相关依赖包
- 通过yum下载rpm包及其依赖包
- 解决RPM包依赖的几种方法
- 解决RPM包依赖的几种方法
- 解决rpm包安装时的循环依赖问题
- 解决redhat红帽的rpm包循环依赖关系
- 解决RPM包依赖的几种方法
- 解决RPM包依赖的几种方法
- centOS中ceph的安装(rpm包依赖安装)
- 解决RPM包依赖的几种方法
- rpm包的依赖关系如何通过yum解决
- yum依赖错误处理:清理重复的rpm包
- 实习笔记7
- IOS开发:CocoaPods安装和使用及问题:Setting up CocoaPods master repo
- 分享做项目心得--随着分辨率变化而做出相应的变化
- 使用WinSCP软件在windows和Linux中进行文件传输
- Android 一些常用的但是记不住的设置
- RPM 包依赖
- TI DSP cmd
- K2与OData和Swagger集成,从任何设备无需代码获取数据
- 【Bugly新技能】带上标签,让你一眼看穿每个异常
- 导入Android Studio 项目报 invalid gradle jdk configuration found
- javascript函数解析2匿名函数,函数直接量
- POJ1003解题报告
- Android Activity启动时黑屏或者白屏的原因
- NSHTTPRequest 请求网络,下载性能优化和断点续传