开发者学堂课程【Linux 软件包安装和 yum 仓库实战：RPM 包管理-1】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：/learning/course/590/detail/8335
RPM 包管理-1
内容简介：
一、Linux 安装软件的两种方式
二、包命名和工具
三、库文件
四、包管理器
一、Linux 安装软件的两种方式
对于 Linux 来讲，安装软件主要有两种方式。
第一种是利用二进制已经编译完了的程序安装。软件包的安装方法本质上就是把那些已经编译好的二进制文件，按照规定的路径知道复制到相应的文件夹，可以直接使用。
第二种方式是源代码。需要人为的去编译，编译结束了以后，还是要安装到目录下，加以配置，之后再来使用。
大体上就是两个类，但是即使拿到的是已经编译完了二进制，真正要用的话，中间还需做些必要的工作。
例如将一些必要的文件，按照程序开发者规定好的路径放到不同的目录中，有些软件可能还要适当的去加配置才能使用，所以中间的这两个步骤。
如果让普通用户去实现，也是稍显繁琐的。因此有很多软件的开发者，就把这两个步骤，用一些方法来解决简化用户使用软件的难度，或者是简化这个过程。
其中红帽公司提出了用 RPM 的包的方式来进行软件的管理，可以轻松解决以上的问题。它把预先定义好的，已经编译完了的二进制文件利用RPM工具，自动的把那些文件复制到、安装到不同的目录下，在一些场合下，可能会增加一些配置搭配。
例如创建对应的一些用户账号等等，给用户准备好环境，直接使用即可，非常便捷。在本章中，除了 RPM 这种方式，还有一种安装方式就是 yum，实际上与 RPM这种方式是一样的只不过 yum 有自己的特点。RPM 包管理软件的常见用法。
那么在 Linux 里面，3DOS 系统中官方，光盘里面带有的这些安装包安装文件与平常 Windows 里用的各种软件不一样。
可以看到红帽的安装光盘里面，安装文件通通的都是一种格式，就是 RPM 格式。那里面有几千个文件。
全是用 RPM 方式来管理和组织安装程序的，接下来学习 Rpm 文件格式的定义。
二、包命名和工具
包:分类和拆包
Application-VERSION-ARCH.rpm: 主包
Application-devel-VERSION-ARCH.rpm 开发子包Application-utils-VERSION-ARHC.rpm其它子包Application-libs-VERSION-ARHC.rpm其它子包
包之间:可能存在依赖关系，甚至循环依赖
解决依赖包管理工具:
yum : rpm 包管理器的前端工具
apt-get : deb 包管理器前端工具
zypper: suse 上的 rpm 前端管理工具
dnf: Fedora 18+ rpm 包管理器前端管理工具
源代码: name-VERSION.tar.gzlbz2lxzVERSION: major.minor.release
rpm包命名方式:
name-VERSION-release.arch.rpm15IJ: bash-4.2.46-19.el7.x86_ 64.rpmVERSION: major.minor.release
release : release.OS
“//光盘的命名方式是这样的，名称，就是包的软件名，再加上版本号，再加上release ，release，也算是个版本号。后面是架构。再加上 rpm 后缀。光盘里面的rpm 包，它的结构基本上都是这种形式的。”
常见的 arch:
x86: i386, i486, i586, i686
x86_ 64: x64, x86 64, amd64powerpc: ppc
跟平台无关: noarch
LastLoginMon15 08:57:28 2018
[root@centos7~]
[root@centos7~]
[rootacentos7~]
[root@centos7~]#df
Filesystem1K-blocksUsed Available Use% Mounted on
/dev/sda252403200 3893692485095088%/
devtmpfs9167240 9167240%/dev
tmpfs9326529326520%/dev/shm
tmpfs932652106169220362%/run
tmpfs9326529326520%/sys/fs/cgroup
/dev/sda33144192034792314071281%data
/dev/sda1103833616855686978017%/boot
tmpfs186532321865001%/run/user/0
/dev/sr091762329176232100%/run/media/root/Centos7
x86_64
[root@centos7 ~]#11 /run/m
mcelog-clientmce1og.pidmdadm/media/mount/
[rootdcentos7 ~]#11 /run/media/root/Centos\ 7\x86_64/
Centos_BuildTagimages/RPM-GPG-KEY-Centos-7
discinfoisolinux/RPM-GPG-KEY-Centos-Testing-7
EFI/Liveos/TRANS.TBL
EULAPackages/treeinfo
GPLrepodata
[root@centos7 ~]
#1s/run/media/root/Centos)7x86_64/Packages/
###
//Windows 的安装光盘已经挂在了当前 run 这个目录下。那在这个目录下有几千个，都是 rpm 为后缀的安装软件包。在 Windows 里，通常在 Windows 里装的软件，只是一个目录而已。
而那个目录解开以后，有好多各种各样的文件，其中有一个安装文件。setup 文件双击安装就行了。但是其他的文件有各种各样的类型。那么在系统中,这个安装包都是打包成了一个 rpm 文件。
Yum-updateboot
//软件的名称
1.1.31
//这个是版本号
版本编号是这个软件的开发者定义的。
在深度系统中,我们很多软件并不是红帽公司开发的，只是一个集成者而已。其中带有的很多软件都是第三方组织不同的组织研发出来的。那么这些组织开发自己的软件的时候，添加的这个软件的版本号，是由这个开发者来维护的。
11.e7x86_64.rpm
//实际上这个是 Cent 系统是红帽公司人为的给他添加的版本。
这个版本,简单的说,组织拿到源码以后，需要用源码进行编译成二进制。那其中编译的过程，需要尝试很多次。
Zip-3.0-11
//11是编译打包的次数。
同一个软件，中间可能经过了若干次编译，这是编译打包的过程，编译的次数介绍。
//虽然软件包是同一个，尝试编译的时候若干次编译。这个编译是基于企业版渗透思的热版本六或七的，是针对 Cpu 架构的。这是 RPM 包它的命名规范。
//要是从一个项目的官方网站看到源码，源码文件格式，没有 11.e7x86_64.rpm，此时源码由文件软件的名称和版本组成。
例如：当下载过 Linux 的源码和 httpd 的源码时，源码包的命名方式就是软件名加版本号加压缩格式。
与渗透思的安装光盘安全包命名方式是不一样的。
实际上只是在后期源码编译的时候，人为加的一些，编译的次数。
x86_64.
//这个是针对什么平台做了编译。源码拿到以后，可以在不同的平台上编译。
x86_64.
1686. rpm
1687.
//例如：可以在32位的 cpu 上编译，也可以在64位的 cpu 上编译。甚至，可以在非英特尔架构的 cpu上进行编译，都没问题。
所以编译完了以后，最终生成二进制之后，文件在什么平台上使用，就会固定下来。
在没有编译的时候，如果只是源码，可以在编译的某些平台上进行使用。
所以这就是互联网上发布的软件很多都是源码的原因，因为考虑到环境不一样。
有的用户选择使用这样的cpu架构，有的用户选择另外另外一些cpu架构。有源码，用户可自由选择平台编辑，所以互联网上很多文件都是源码发布。
//当然，渗透思的安装光盘是已经编辑完成的，因为光盘给用户的时候已经明确的告诉用户，这个光盘就是适合于64位的cpu或英特尔cpu架构的安装光盘，所以里面的这些包也都是只适合于英特尔的64位的架构的平台上去使用。除了常见的X86、64这种 cpu 架构，事实上也有一些非英特尔架构如 Powerpc、ppc。Adm 有自己的 cpu 架构。
计算机基础中很多种类型的计算机，当然，英特尔 cpu 是主流，但是也有一些其他类型的 cpu。
对于一个软件，如果它比较复杂的话。通常采用拆包的方式。
Yum-plugin 代表着 Yum-插件，实际上它本身就有各种各样的插件。
分成了很多类别。包括 Zipb 实际上是基于 matlab 的库，这是一种程序编开发库，这种库又给用户拆分成了若干个类别，若干个子类，为了使用软件的时候更加灵活，一个大类型的包往往拆分成了多种小类型子类型。
将来用到哪个子类型的包，可以单独按装，而不至于说就想装一个小的类别还需要把所有的类别都装上。
假设你有一个 application 应用程序，可能涉及到开发包工具包，以及相关的库包，把同一类型的应用程序的包给用户。
已经编译完了的二进制程序，正如在 Windows 上安装一些软件一样。Windows 安装软件不是说拿到安装程序，直接双击安装就能够顺利的安装的。在有些场景下，会发现在用户安装一些 Windows 软件，系统可能会提示用户：缺少哪些程序文件。
有的时候，系统说缺少程序之类的，用户就会收到提示。软件官方给用户提供那个软件包，可能并不是很完整的。它可能会依赖于Windows上一些现有的程序。用户需要事先把这些依赖的那些程序先装好，才能把这些软件装上。
同样的道理，在 Linux 里安装一个 RPM 包，可能也有依赖性。这种依赖性，就导致用户在装某个包的时候，安装时，会收到系统提醒。系统提醒缺 B 包时，用户先把 B 包装上。当然，用户装B包后发现B包可能又依赖于 C 包。
//这种依赖性是很严重的，不像平时在 Windows 安装软件，依赖性不多。当然因为系统要保证用户体验较好，所以大部分情况下安装软件都是比较顺利。只是偶尔个别情况下缺一些某些包，在 Linux 里面，rpm 包这种依赖性是比较多的，因为每个包都不大，所以用户安装某个包，会依赖着别的包，可能都已经有独立的 rpm包。而且这些 rpm 包不一定已经装上。，所以系统这时候，就提醒用户缺少某个包。
甚至可能还会出现循环依赖，所谓循环依赖，那就是A依赖于B，B依赖于C，C依赖于 A。当出现这样的问题时 ABC 包要一起装。
当然对于 RPM 的依赖性，没有办法来解决。可以一下子装多个包，后面跟多个包名称，但是这种包的依赖性，不能够自动的把依赖的包找到并且安装，只能一个一个的装。
用户缺什么，系统就提醒用户，然后用户再找那个依赖包再安装，装的时候还可能提醒用户依赖于别的包。对于cent OS的系统来讲，包的依赖性的解决方案就是用yum。当然渗透思的系统版本后期，不断的更迭和升级，那后期可能会有这样的一个 dnf 包的解决方案来代替。
//dnf 包是在 fedora18 这个版本以后,能够解决依赖性的包。DNF 的效率要更高，安装速度要更快。Dnf 使用和 yum 实际上基本上一样，就是命令给变成 DNF。对于非红帽的光盘，解决方案不一样。这样的一些其他的解决方案。例如 deb 可以用Apt -get。Suse 的用 zypper。不同的工具和版本，它的解决方案是不一样的。
三、库文件
查看二进制程序所依赖的库文件
ldd /PATH/TO/BINARY FILE
管理及查看本机装载的库文件
ldconfig
加载配置文件中指定的库文件
/sbin/ldconfig -p显示本机已经缓存的所有可用库文件名及文件路径
映射关系
配置文件: /etc/ld.so.conf, /etc/ld.so.conf.d/* .conf
缓存文件: /etc/ld.so.cache
Indexof/epel/
4AS/I11-Apr-2017 15:2811-Apr-2017 15:28
4ES/11-Apr-2017 15:28
49S/11-Apr-2017 15:28
5
11-Apr-2017 15:31
5Client/11-Apr-2017 15:31
11-Apr-2017 15:31
5Seryer
26-0ct-2017 09:49
6Serverl26-0ct-2017 09:49
26-0ct-201700:25
7Server/26-0ct-201700:25
project22-Nov-2017 14:00
teetingl30-Aug-2014 16:49
EPM-GPC-KEY-EPEL03-ar-2007 14:111698
EPM-GFG-KEY-EPEL-403-1ar-2007 14:111698
RPI-GPG-KEY-EPEL-503-ar-2007 14:111698
RPM-GPG-KEY-EPEL-612-1ay-201001:251649
RPI-GPG-KEY-EPEL-6Server12-ay-2010 01:251649
RPU-GPG-KEY-EPEL-7
RPI-GPG-KEY-EPEL-7Server20-Jun-2014 18:54
20-Jun-2014 18:5416621662
tnelcrelease-latest-6.noarch.rpm05-Nov-2012 15:3114540
cpel-release-latest-7.noarch rp02-0ct-2017 17:5215080
fullfilelist12-0ct-2018 21:49170444355
fullfiletimelist-erel12-0ct-2018 21:349886192
inageliat-epel23-Nov-2016 18:200
四、包管理器
程序包管理器:
功能:将编译好的应用程序的各组成文件打包一个或几个程序包文件,从而
方便快捷地实现程序包的安装、卸载、查询、升级和校验等管理操作
包文件组成(每个包独有)
RPM 包内的文件
RPM 的元数据,如名称，版本，依赖性,描述等
安装或卸载时运行的脚本
数据库(公共) : /var/lib/rpm
程序包名称及版本
依赖关系
功能说明
包安装后生成的各文件路径及校验码信息
程序包的来源
管理程序包的方式:
使用包管理器: rpm
使用前端工具: yum, dnf
获取程序包的途径:
(1)系统发版的光盘或官方的服务器
CentOS 镜像:
https://www.centos.org/download/http://mirrors.aliyun.com
http://mirrors.sohu.com
http://mirrors.163.com
(2)项目官方站点
3)第三方组织:
Fedora-EPEL :
Extra Packages for Enterprise Linux
Rpmforge:RHEL 推荐,包很全
搜索引擎:
http://pkgs.org
http://rpmfind.net
http://rpm.pbone.net
https://sourceforge.net/
(4)自己制作
注意: 第三方包建议要检查其合法性
来源合法性,程序包的完整性
Rpm 包管理
CentOS 系统上使用 rpm 命令管理程序包:
安装、卸载、升级、查询、校验、数据库维护安装:
rpm {-i--instal} [install-options] PACKAGE FILE..
-V: verbose
-VV:
-h:以#显示程序包管理执行进度
rpm -ivh PACKAGE FILE...
