RPM包管理工具详解总结
为什么会有RPM包管理工具
Linux系统安装软件有两种方法
- 拿到软件源代码, 自己手动编译, 然后把编程之后的二进制文件存放到指定的目录下, 并手动编写一些相关的配置文件.
- 利用已经编译好的二进制文件安装, 但还是需要把这些文件存放到指定的目录下, 并手动编写一些相关的配置文件.
对于一般用户来说, 存放文件到指定目录 并 手动编写配置文件 的过程是及其繁琐的, 因此为了简化用户安装软件的过程, 开发者们都会编写一些工具来帮助用户自动进行这些过程, 而红帽公司提出的RPM(Red-Hat Package Manage)包管理工具就是这样的一种工具.
RPM包管理工具只能管理以.rpm
为后缀的包文件.
软件源代码编译成二进制文件后被打包成以.rpm
后缀名结尾的RPM包, RPM工具会将RPM包中的文件自动存放都指定目录下并根据需要创建一些配置文件
RPM包管理工具是只有CentOS系统采用的, Ubuntu系统采用的是dpkg和apt工具
RPM包的命名
命名格式
name-version-release.arch.rpm
name: 软件的名字
version: 软件的版本号
release: 红帽公司拿到软件源码后编译的次数以及针对的操作系统版本
arch: 编译的cpu架构
补充说明
- Centos操作系统中的软件并非全部由红帽公司开发, 有许多都是由第三方公司开发, 而红帽公司只是一个集成的作用, 将软件的源代码拿来后针对某个Centos的版本在一个指定cpu架构下进行编译, 编译后的软件也只能在特定的cpu架构下运行.
- 互联网上发布的软件大多数都是以源码的形式发布, 因为无法确定使用者的编译环境, 而源码在任何环境下都能够编译.
- el7 表示Centos7, el6表示Centos6
- 常见的arch由x86_64 表示英特尔64位的cpu架构, noarch表示未指定特定的cpu架构
- 例子
- vim-filesystem-7.4.629-6.el7.x86_64.rpm
针对Centos7编译了6次, 64位cpu下才能执行 - firewalld-filesystem-0.6.3-2.el7.noarch.rpm
针对Centos7编译了2次, 所有平台都可执行
- vim-filesystem-7.4.629-6.el7.x86_64.rpm
RPM包的拆分与依赖
为了使软件的安装更加灵活, 一个软件包通常会被拆分成许多子包, 用户可以根据需要安装特定子包, 而不必为了某一个小功能而安装所有的包.
比如一个主包可以被拆分为-devel 开发包; -utils 工具包; -libs 其它子包.
每一件事都需要辩证地看待, 包的拆分虽然使得用户的安装更加灵活, 但也带来了一些其它的问题, 比如一些子包为了完成某些功能必须和其余的包一起使用, 因此就产生了包的依赖, 即安装某个包时, 必须先安装另外的某些包, 否则该包无法安装. 有时候甚至还存在循环依赖, 即A包依赖B包, B包依赖C包, C包依赖A包, 这时候必须同时安装这些包.
RPM工具并没有很好的解决包的依赖性, 用户只能通过每次安装时显示的提示信息去寻找对应的依赖继续安装, 但是当依赖包非常多的时候, RPM工具就显得有些乏力, 因此就有了YUM工具. 具体介绍见下一篇博文
二进制程序的依赖库
其实不止RPM包之间存在依赖关系, 系统中的绝大多数二进制执行文件(命令)都会依赖一些系统库, 有些系统库甚至被多个二进制程序所依赖, 不小心删除了某些系统通用库可能会导致整个系统崩溃.
-
查询某个二进制执行程序运行所依赖的库
ldd /path/to/binary_file
[root@centos7 ~]# ldd /bin/ls linux-vdso.so.1 => (0x00007ffcab7cb000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fd26fe86000) libcap.so.2 => /lib64/libcap.so.2 (0x00007fd26fc81000) libacl.so.1 => /lib64/libacl.so.1 (0x00007fd26fa78000) libc.so.6 => /lib64/libc.so.6 (0x00007fd26f6aa000) libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fd26f448000) libdl.so.2 =>