RPM 全稱為：Red-Hat Package Manager，即紅帽 Linux 發(fā)行版的軟件包管理器。RPM 的出現(xiàn)，提升了 Linux 軟件安裝、升級的便捷性。RPM 遵循 GPL 協(xié)議，除了紅帽 Linux 發(fā)行版，Caldera OpenLinux、SUSE 以及 Turbo Linux 等 Linux 的發(fā)行版也使用 RPM，因此 RPM 是 Linux 軟件包管理的行業(yè)標(biāo)準(zhǔn)。為了使讀者能夠較為深入理解 RPM，我們先介紹軟件的構(gòu)建方法。
計算機(jī)軟件的軟件是從源代碼構(gòu)建出來的。源代碼是人們以人類可讀的語言書寫的、讓計算機(jī)執(zhí)行任務(wù)的指令。人類可讀的語言格式和規(guī)范，就是編程語言。
從源代碼制作軟件的過程，稱之為是軟件編譯。從源代碼構(gòu)建成軟件的編譯有兩種方式：
本機(jī)編譯方式下，代碼可以獨(dú)立編譯成機(jī)器代碼或直接編譯為二進(jìn)制文件可執(zhí)行文件。本機(jī)編譯構(gòu)建的軟件包中，包含編譯環(huán)境下計算機(jī)體系架構(gòu)的特征。例如，使用 64 位（x86_64）AMD 計算機(jī)中編譯的軟件，不能在 Intel 處理器架構(gòu)上運(yùn)行。
與本機(jī)編譯可以獨(dú)立執(zhí)行相對應(yīng)，某些編程語言不能將軟件編譯成計算機(jī)可以直接理解的格式，而需要語言解釋器或語言虛擬機(jī)（如 JVM），我們稱之為解釋編譯。常用的解釋語言有 Byte Compiled（源代碼需要編譯成字節(jié)代碼，然后由語言虛擬機(jī)執(zhí)行，如 Python）和 Raw Interpreted（原始解釋語言完全不需要編譯，它們由解釋器直接執(zhí)行，如 Bash shell）兩種。
我們常用的 bash shell 和 Python 是解釋型的，這種方式編譯出的程序與硬件架構(gòu)無關(guān)，通過這種方式編譯出的 RPM 會被標(biāo)注為 noarch（說明 RPM 包不依賴于特定 linux 發(fā)行版）。
在介紹了源代碼的編譯方式后，接下來我們通過實(shí)驗(yàn)的方式展現(xiàn)軟件的編譯過程。
在正式開始驗(yàn)證之前，我們需要在 Linux 中安裝編譯工具。
# yum install gcc rpm-build rpm-devel rpmlint make python bash coreutils diffutils接下來，我們分別介紹本機(jī)編譯和解釋編譯。
在編程語言中，C 語言是本機(jī)編譯。我們查看一個源代碼文件，如清單 1 所示：
# cat cello.c
#include <stdio.h>
int main(void) {
printf("Hello World, I'm DavidWei!\n");
return 0;
}調(diào)用 C 編譯器 gcc 進(jìn)行編譯：
# gcc -o cello cello.c
編譯成功后，我們可以執(zhí)行結(jié)果輸出。
# ./cello
Hello World, I'm DavidWei!
為了實(shí)現(xiàn)自動化構(gòu)建代碼，我們添加 Makefile，這是大型軟件開發(fā)中常用的方法。
首先創(chuàng)建一個 Makefile，如清單 2 所示：
# cat Makefile
cello:
gcc -o cello cello.c
clean:
rm cello接下來，通過 make 來完成編譯。
執(zhí)行 make 會自動編譯源代碼，然后可以成功執(zhí)行，如下圖 1 所示：
執(zhí)行 make clean 會刪除編譯結(jié)果，如下圖 2 所示：圖 2. 刪除編譯結(jié)果
在介紹了本機(jī)編譯后，我們介紹解釋編譯。
對于用解釋型編程語言編寫的軟件，如果是 Byte Compiled 語言如 Python，就需要一個編譯步驟，把源代碼構(gòu)建成 Python 的語言解釋器（稱為 CPython）的可以執(zhí)行文件。
我們查看一個 python 的源代碼，如清單 3 所示：
# cat pello.py
#!/usr/bin/env python
print("Hello World, I'm DavidWei!")對源代碼進(jìn)行編譯：
# python -m compileall pello.py
Compiling pello.py ...
編譯成功后運(yùn)行：
# python pello.pyc
Hello World, I'm DavidWei!
我們看到，對源.py 文件進(jìn)行字節(jié)編譯后會生成一個.pyc 文件，這是 python 2.7 字節(jié)編譯的文件類型，這個文件可以使用 python 語言虛擬機(jī)運(yùn)行。
查看文件類型：
# file pello.pyc
pello.pyc: python 2.7 byte-compiled
和 python 相對應(yīng)，無需編譯的解釋性代碼是 Raw Interpreted，如我們?nèi)粘Ｊ褂玫?bash shell。
我們看一個 shell 文件，如清單 4 所示：
# cat bello
#!/bin/bash
printf "Hello World, I'm DavidWei!\n"對于 Raw Interpreted 源碼，我們使文件可執(zhí)行、然后直接運(yùn)行即可，如下圖 3 所示：
圖 3. 修改權(quán)限運(yùn)行 shell
在介紹了如何從源碼構(gòu)建軟件包后，接下來我們介紹如何給軟件打補(bǔ)丁。
在計算機(jī)軟件中，補(bǔ)丁是用來修復(fù)代碼中的漏洞的。軟件中的補(bǔ)丁表示的是與源代碼之間的不同之處。接下來，我們從原始源代碼創(chuàng)建補(bǔ)丁，然后應(yīng)用補(bǔ)丁。
創(chuàng)建補(bǔ)丁的第一步是備份原始源代碼，通常是將它拷貝為.orig 文件。我們以 cello.c 為例。
首先備份 cello.c，然后修改 cello.c 中的內(nèi)容，如下圖 4 所示，我們修改了源代碼中的描述：
圖 4. 備份并修改源碼
首先查看兩個源碼文件的不同之處，如下圖 5 所示：
圖 5. 查看兩個源碼文件的不同
將兩個源碼的不同之處保存到 cello-output-first-patch.patch 中。
# diff -Naur cello.c.orig cello.c > cello-output-first-patch.patch
為了驗(yàn)證打補(bǔ)丁的效果，將 cello.c 文件恢復(fù)為原始源代碼，如下圖 6 所示：
圖 6. 恢復(fù) cello.c 初始內(nèi)容
將補(bǔ)丁文件重定向到補(bǔ)丁，給源碼打補(bǔ)丁，如下圖 7 所示。
圖 7. 給源碼打補(bǔ)丁
從上圖 cat 命令的輸出中可以看到補(bǔ)丁已成功構(gòu)建并運(yùn)行，如圖 8 所示：
圖 8. 構(gòu)建源碼并運(yùn)行
至此，證明為打補(bǔ)丁成功。
一旦我們構(gòu)建了軟件，我們就可以將它放在系統(tǒng)的某個目錄下，以便用戶可以執(zhí)行。為了方便操作，很多時候我們需要將編譯和安裝進(jìn)行合并。
對于不需要編譯類的解釋型語言，例如 shell，可以使用 install 命令安裝到 linux 中，如下圖 9 所示：
圖 9. 安裝并執(zhí)行 shell
對于需要編譯的語言，就需要先編譯再安裝。例如使用 make install。修改 makefile 文件，如下圖 10 所示：
圖 10. 修改 Makefile
構(gòu)建并安裝 cello.c 程序，并執(zhí)行驗(yàn)證成功，如下圖 11 所示：
圖 11. 構(gòu)建并安裝 cello.c
我們剛展示的是編譯與安裝在相同的環(huán)境下，即可以通過 Makefile 的方式，直接編譯和安裝程序；如果編譯和運(yùn)行是兩個環(huán)境，那么我們就需要對軟件進(jìn)行 RPM 打包。在 RPM 打包之前，需要將源代碼進(jìn)行打包生成 tar.gz 文件。
在源碼打包時，需要在每個源代碼版本中包含一個 LICENSE 文件。我們模擬生成遵守 GPLv3 的壓縮包，如下圖 12 所示：
圖 12. 生成 LICENSE 文件
將 bello 程序的源碼打包，如下圖 13 所示：
圖 13. 將 bello 程序的源碼打包
創(chuàng)建~/rpmbuild/SOURCES 目錄，將.tar.gz 文件移動過去，如下圖 14 所示：
圖 14. 移動 tar.gz 包
用相同的方法，我們?yōu)?Pello 和 Cello 的源碼打包，由于方法相同因此不再贅述。
將源碼打包以后，接下來我們就可以使用 RPM 將其構(gòu)建成 RPM 包。
RPM 文件有兩類：源 RPM（SRPM）和二進(jìn)制 RPM。SRPM 中的有效負(fù)載是 SPEC 文件（描述如何構(gòu)建二進(jìn)制 RPM）。
查看 SRPM 的目錄結(jié)構(gòu)，如下圖 15 所示：
圖 15. 查看 SRPM 目錄結(jié)構(gòu)
上圖中 SRPM 五個目錄的作用分別是：
BUILD構(gòu)建 RPM 包的時，會在此目錄下產(chǎn)生各種%buildroot 目錄。如果構(gòu)建失敗，可以據(jù)此查看目錄日志，進(jìn)行問題診斷。RPMS構(gòu)建成功二進(jìn)制 RPM 的存放目錄。存放在 architecture 的子目錄中。例如：noarch 和 x86_64SOURCES存放源代碼和補(bǔ)丁的目錄。構(gòu)建 RPM 包時，rpmbuild 命令將會從這個目錄查找源代碼。SPECSSPEC 文件存放目錄SRPMS存放 SRPM 的目錄
在介紹了 SRPM 的目錄結(jié)構(gòu)后，我們詳細(xì)介紹 SPEC 的作用。
SPEC 文件是 rpmbuild 程序用于實(shí)際構(gòu)建 RPM 的方法。SPEC 文件包含如下字段：
SPEC DirectiveDefinitionName包的名稱，應(yīng)與 SPEC 文件名匹配Version軟件的上游版本號。ReleaseRPM 軟件版本號。初始值通常應(yīng)為 1％{？dist}，并在一個新版本構(gòu)建時重置為 1.SummaryRPM 包的簡要說明License正在打包的軟件的許可證。URL該程序的更多信息的完整 URL（通常是打包的軟件的上游項(xiàng)目網(wǎng)站）。Source0上游源代碼的壓縮歸檔的路徑或 URL
如果需要，可以添加更多的 SourceX 指令，每次遞增數(shù)字，例如：Source1，Source2，Source3，依此類推Patch0應(yīng)用于源代碼的第一個補(bǔ)丁的名稱。
如果需要，可以添加更多 PatchX 指令，增加每次編號如：Patch1，Patch2，Patch3 等。BuildArch表示 RPM 包的構(gòu)建的計算機(jī)架構(gòu)。如果包不依賴于體系結(jié)構(gòu)，即完全用于編寫解釋的編程語言，這應(yīng)該是 BuildArch：noarch。BuildRequires編譯軟件包所需的依賴包列表，以逗號分隔。Requires安裝軟件包時所需的依賴包列表，以逗號分隔。ExcludeArch如果某個軟件無法在特定處理器架構(gòu)下運(yùn)行，在此進(jìn)行指定。
在運(yùn)維過程中，我們經(jīng)常會查看到一個 RPM 包的 Name、Version、Release。這個字段就是在 SPEC 文件中定義的。
例如，我們要查詢 Python RPM 包版本，如下圖 16 所示：
圖 16. 查看 python 版本
在上圖的輸出中：python 是 Name、2.7.5 是 Version、58.el7 是 Release、x86_64 是 BuildArch。這些信息都是在 SPEC 中定義的。
接下來，我們介紹 RPM SPEC 文件中使用的語法。
SPEC DirectiveDefinition%description完整描述了 RPM 中打包的軟件，可以包含多行并分成段落。%prep打包準(zhǔn)備階段執(zhí)行一些命令%build包含構(gòu)建階段執(zhí)行的命令，構(gòu)建完成后便開始后續(xù)安裝。%install包含安裝階段執(zhí)行的命令。%check包含測試階段執(zhí)行的命令。%files需要被打包/安裝的文件列表。%changelogRPM 包變更日志。
在介紹了 SEPC 的格式和語法后，接下來我們介紹如何書寫 SPEC 并構(gòu)建 RPM 包。
在打包新軟件時，可以通過 rpmdev-newspec 工具創(chuàng)建一個新的 SPEC 文件，然后據(jù)此進(jìn)行修改。
首先，我們通過三個源碼文件生成三個 SPEC，如下圖 17 所示：
圖 17. 生成 SPEC 文件
點(diǎn)擊查看大圖
.SPEC 已經(jīng)生成，如下圖 18 所示：
圖 18.查看生成的 SPEC 文件
接下來我們?yōu)槿齻€ SRPM 書寫 SPEC，描述如下：
Software NameExplanation of examplebello基于 bash 書寫的。不需要構(gòu)建但只需要安裝文件。 如果是預(yù)編譯的二進(jìn)制文件需要打包，這種方法也可以使用，因?yàn)槎M(jìn)制文件也只是一個文件。pello基于 Python 書寫的軟件。用 byte-compiled 的解釋編程語言編寫的軟件，用于演示字節(jié)編譯過程的安裝和安裝生成的預(yù)優(yōu)化文件。cello基于 C 書寫的軟件。用 natively compiled 的編程語言編寫的軟件，演示使用工具的常見構(gòu)建和安裝過程以及編譯本機(jī)代碼。
由于三個 SPEC 修改的思路類似，因此我們只細(xì)致介紹 bello 的 SPEC 修改步驟。
生成的 bello.spec 文件內(nèi)容如清單 5 所示：
# cat bello.spec
Name: bello
Version:
Release: 1%{?dist}
Summary:
License:
URL:
Source0:
BuildRequires:
Requires:
%description
%prep
%setup -q
%build
%configure
make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
%make_install
%files
%doc
%changelog修改后的 bello.spec 內(nèi)容如清單 6 所示：
[root@rpmlab-d710 ~]# cat ~/rpmbuild/SPECS/bello.spec
Name: bello
Version: 0.1
Release: 1%{?dist}
Summary: Hello World example implemented in bash script
License: GPLv3+
URL: https://www.example.com/%{name}
Source0: https://www.example.com/%{name}/releases/%{name}-%{version}.tar.gz
Requires: bash
BuildArch: noarch
%description
The long-tail description for our Hello World Example implemented in
bash script of DavidWei.
%prep
%setup -q
%build
%install
mkdir -p %{buildroot}%{_bindir}
install -m 0755 %{name} %{buildroot}%{_bindir}/%{name}
%files
%license LICENSE
%{_bindir}/%{name}
%changelog
* Tue Jun 29 2019 DavidWei - 0.1-1
- First bello package
- Example second item in the changelog for version-release 0.1-1在修改完 SEPC 后，我們就可以根據(jù)源代碼和 SPEC 文件構(gòu)建軟件包。
實(shí)際上，我們在構(gòu)建二進(jìn)制 RPM 包時，有兩種構(gòu)建方法：
然而，在軟件開發(fā)中，我們通常會采用第一種方法，因?yàn)樗幸韵聝?yōu)勢：
由于篇幅有限，本文只展示從源碼構(gòu)建 SRPM，再從 SRPM 構(gòu)建二進(jìn)制 RPM 的步驟。
下面我們演示如何通過源碼和剛修改的 SPEC 文件構(gòu)建 Source RPM 并在構(gòu)建時指定-bs 參數(shù)（如果使用-bb 參數(shù)，則直接生成二進(jìn)制 RPM），以便生成 SRPM，如下圖 19 所示：
首先，我們基于 SRPM 生成二進(jìn)制 RPM。執(zhí)行過程如清單 7 所示：
# rpmbuild --rebuild ~/rpmbuild/SRPMS/bello-0.1-1.el7.src.rpm
Installing /root/rpmbuild/SRPMS/bello-0.1-1.el7.src.rpm
warning: bogus date in %changelog: Tue Jun 29 2019 DavidWei - 0.1-1
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.hNMkOC
+ umask 022
+ cd /root/rpmbuild/BUILD
+ cd /root/rpmbuild/BUILD
+ rm -rf bello-0.1
+ /usr/bin/tar -xf -
+ /usr/bin/gzip -dc /root/rpmbuild/SOURCES/bello-0.1.tar.gz
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd bello-0.1
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.0isn4Y
+ umask 022
+ cd /root/rpmbuild/BUILD
+ cd bello-0.1
+ exit 0
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.epoHml
+ umask 022
+ cd /root/rpmbuild/BUILD
+ '[' /root/rpmbuild/BUILDROOT/bello-0.1-1.el7.x86_64 '!=' / ']'
+ rm -rf /root/rpmbuild/BUILDROOT/bello-0.1-1.el7.x86_64
++ dirname /root/rpmbuild/BUILDROOT/bello-0.1-1.el7.x86_64
+ mkdir -p /root/rpmbuild/BUILDROOT
+ mkdir /root/rpmbuild/BUILDROOT/bello-0.1-1.el7.x86_64
+ cd bello-0.1
+ mkdir -p /root/rpmbuild/BUILDROOT/bello-0.1-1.el7.x86_64/usr/bin
+ install -m 0755 bello /root/rpmbuild/BUILDROOT/bello-0.1-1.el7.x86_64/usr/bin/bello
+ /usr/lib/rpm/find-debuginfo.sh --strict-build-id -m --run-dwz --dwz-low-mem-die-limit 10000000 --dwz-max-die-limit 110000000 /root/rpmbuild/BUILD/bello-0.1
/usr/lib/rpm/sepdebugcrcfix: Updated 0 CRC32s, 0 CRC32s did match.
+ '[' noarch=noarch ']'
+ case "${QA_CHECK_RPATHS:-}" in
+ /usr/lib/rpm/check-buildroot
+ /usr/lib/rpm/redhat/brp-compress
+ /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip
+ /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1
+ /usr/lib/rpm/redhat/brp-python-hardlink
+ /usr/lib/rpm/redhat/brp-java-repack-jars
Processing files: bello-0.1-1.el7.noarch
Executing(%license): /bin/sh -e /var/tmp/rpm-tmp.hV1l1H
+ umask 022
+ cd /root/rpmbuild/BUILD
+ cd bello-0.1
+ LICENSEDIR=/root/rpmbuild/BUILDROOT/bello-0.1-1.el7.x86_64/usr/share/licenses/bello-0.1
+ export LICENSEDIR
+ /usr/bin/mkdir -p /root/rpmbuild/BUILDROOT/bello-0.1-1.el7.x86_64/usr/share/licenses/bello-0.1
+ cp -pr LICENSE /root/rpmbuild/BUILDROOT/bello-0.1-1.el7.x86_64/usr/share/licenses/bello-0.1
+ exit 0
Provides: bello=0.1-1.el7
Requires(rpmlib): rpmlib(CompressedFileNames) <=3.0.4-1 rpmlib(FileDigests) <=4.6.0-1 rpmlib(PayloadFilesHavePrefix) <=4.0-1
Requires: /bin/bash
Checking for unpackaged file(s): /usr/lib/rpm/check-files /root/rpmbuild/BUILDROOT/bello-0.1-1.el7.x86_64
Wrote: /root/rpmbuild/RPMS/noarch/bello-0.1-1.el7.noarch.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.PCJIAr
+ umask 022
+ cd /root/rpmbuild/BUILD
+ cd bello-0.1
+ /usr/bin/rm -rf /root/rpmbuild/BUILDROOT/bello-0.1-1.el7.x86_64
+ exit 0
Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.ift0pO
+ umask 022
+ cd /root/rpmbuild/BUILD
+ rm -rf bello-0.1
+ exit 0二進(jìn)制 RPM 構(gòu)建成功后，可以在~/rpmbuild/RPMS/中找到生成的二進(jìn)制 RPM：bello-0.1-1.el7.noarch.rpm，如下圖 20 所示：
通過 SRPM 構(gòu)建成二進(jìn)制 RPM 后，源碼會被自動刪除。如果想恢復(fù)源碼，需要安裝 srpm，如下圖 21 所示：
現(xiàn)在我們檢查生成的二進(jìn)制 RPM 的正確性并進(jìn)行安裝。
Rpmlint 命令可以檢查二進(jìn)制 RPM、SRPMs 和 SPEC 文件的正確性。
我們以 bello.spec 為例進(jìn)行檢查。
# rpmlint bello.spec
bello.spec: E: specfile-error warning: bogus date in %changelog: Tue Jun 29 2019 DavidWei - 0.1-1
0 packages and 1 specfiles checked; 1 errors, 0 warnings.從 bello.spec 的檢查結(jié)果中，發(fā)現(xiàn)一個 error。具體報錯描述我們需要檢查 srpm。
# rpmlint ~/rpmbuild/SRPMS/bello-0.1-1.el7.src.rpm
bello.src: W: invalid-url URL: https://www.example.com/bello HTTP Error 404: Not Found
bello.src: E: specfile-error warning: bogus date in %changelog: Tue Jun 29 2019 DavidWei - 0.1-1
1 packages and 0 specfiles checked; 1 errors, 1 warnings.從檢查 SRPM 的結(jié)果可以看出，報錯的原因是 URL（https://www.example.com/bello）無法訪問。我們修改 SEPC，將地址設(shè)置為可訪問地址，如下圖 22 所示：
修改成功后再重新編譯后檢查，重新驗(yàn)證二進(jìn)制 RPM 正確性，error 數(shù)量為 0，如下圖 23 所示：
最后，安裝編譯好的 rpm 包并運(yùn)行程序進(jìn)行驗(yàn)證，如下圖 24 所示：
我們看到，上圖中執(zhí)行 bello 程序成功，證明 RPM 安裝成功。
在前文中我們已經(jīng)提到，有的 RPM 包與運(yùn)行環(huán)境有關(guān)，有的無關(guān)。如果一個 RPM 依賴于某一個版本的運(yùn)行環(huán)境（linux 版本或處理器架構(gòu)），我們?nèi)绾巫屵@個 RPM 在其他的環(huán)境中運(yùn)行？這涉及到異構(gòu)環(huán)境下的 RPM 重新編譯。
Mock 是一個用于構(gòu)建 RPM 包的工具（就像 docker 啟動一個 build 的環(huán)境一樣，擺脫對編譯環(huán)境 linux 版本的限制）。它可以為不同的架構(gòu)、Linux 版本構(gòu)建 RPM 軟件包。在 RHEL 系統(tǒng)上使用 Mock，需要啟用"Extra Packages for Enterprise Linux"（EPEL）存儲庫。
針對 RPM 包，Mock 最常見的用例之一是創(chuàng)建原始的構(gòu)建環(huán)境。通過指定不同的配置文件（/etc/mock 目錄下）即模擬使用不同的構(gòu)建環(huán)境。
查看 mock 配置文件，如下圖 25 所示：
我們以 epel-7-x86_64.cfg 為例，查看其中關(guān)于架構(gòu)的描述，如清單 8 所示，可以看到是 x86_64 和紅帽 Linux 發(fā)行版 7 的信息：
[root@master mock]# cat epel-7-x86_64.cfg |grep -i arch
config_opts['target_arch']='x86_64'
config_opts['legal_host_arches']=('x86_64',)
mirrorlist=http://mirrorlist.centos.org/?release=7& arch=x86_64& repo=os
mirrorlist=http://mirrorlist.centos.org/?release=7& arch=x86_64& repo=updates
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-7& arch=x86_64
mirrorlist=http://mirrorlist.centos.org/?release=7& arch=x86_64& repo=extras
mirrorlist=http://mirrorlist.centos.org/?release=7& arch=x86_64& repo=sclo-rh
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=testing-epel7& arch=x86_64
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-debug-7& arch=x86_64使用 epel-7-x86_64 配置來構(gòu)建 SRPM，如下圖 26 所示：
使用 epel-6-x86_64 配置來構(gòu)建 SRPM，如下圖 27 所示：
查看構(gòu)建好的二進(jìn)制 rpm：cello-1.0-1.el6.x86_64.rpm，如下圖 28 所示：
安裝 cello-1.0-1.el6.x86_64.rpm，如下圖所示：
點(diǎn)擊查看大圖
查看構(gòu)建好的二進(jìn)制 RPM cello-1.0-1.el7.x86_64.rpm，并進(jìn)行安裝驗(yàn)證，如下圖 30 所示：
圖 30. 安裝構(gòu)建好的二進(jìn)制 RPM
至此，在異構(gòu)環(huán)境下重新編譯二進(jìn)制 RPM 成功。
通過本文，相信您對通過源碼構(gòu)建成 RPM 有了較為深刻的理解。隨著開源理念的不斷普及，越來越多的客戶將業(yè)務(wù)系統(tǒng)從 Windows 遷移到 Linux 上，理解了 Linux 中的 RPM 打包方式，會對以后我們?nèi)粘５墓ぷ饔泻艽蟮膸椭?/p>
原文：https://www.ibm.com/developerworks/cn/linux/l-lo-rpm-build-package/index.html
前市面上的一體式水冷散熱器還是以240/360水冷為主，如果只看性能的話當(dāng)然冷排尺寸越大，散熱效果越好，不過旗艦級的360水冷并不能安裝在數(shù)量眾多的MATX機(jī)箱里。NZXT（恩杰）Kraken X63 RGB水冷散熱器是一款280水冷，在保證了散熱效果的同時也能擁有不錯的兼容性，一起來看看吧。
規(guī)格參數(shù)
散熱器尺寸：315mm×143mm×30mm
冷頭尺寸：79mm×79mm×52mm
水泵速度：800~2800±300 RPM
風(fēng)扇規(guī)格：AER RGB 2 140mm×2，500~1800RPM±300 RPM
控制類型：CAM軟件控制
參考價格：1299元
從外觀設(shè)計來看，Kraken X63 RGB延續(xù)了NZXT家族化的外觀風(fēng)格，和之前的X62區(qū)別不大，屬于X系列280水冷的第四代產(chǎn)品。與基礎(chǔ)款相比，RGB版本最大的特點(diǎn)就是增加了純白配色，冷排、水管和水冷頭均采用白色涂裝，給那些追求簡約時尚和小清新風(fēng)格的玩家提供了高顏值的新選擇。
NZXT Kraken X63 RGB的水冷頭配備了X系列標(biāo)志性的“無限鏡”設(shè)計，升級后的無限燈環(huán)相比之前加大10%，擁有更加獨(dú)特酷炫的無限反射RGB燈光效果。并且具備可獨(dú)立定址的RGB通道，通過專用的CAM軟件即可獨(dú)立控制Logo與光環(huán)的燈光效果。同時Logo的方向可以以30°的角度旋轉(zhuǎn)調(diào)節(jié)，讓玩家在打造ITX主機(jī)的水冷系統(tǒng)時不用擔(dān)心水冷頭的安裝方向。
水冷頭采用第七代Asetek水泵，性能強(qiáng)勁，水冷頭底座采用銅底銑底工藝，可以帶來與處理器更好的接觸效果，底座上已經(jīng)預(yù)涂了硅脂涂，用戶拿到手就可以直接安裝。冷頭側(cè)面有兩個接口，一個是特殊定制的X3接口，用于連接SATA電源、RGB信號、風(fēng)扇供電等，另一個是MicroUSB接口，用于連接主板前置USB 2.0接口。值得一提的是，冷頭的HUE 2輸出通道支持ARGB串聯(lián)，最多4可以串聯(lián)4根LED燈條或者RGB電纜梳來進(jìn)一步強(qiáng)化機(jī)箱燈效。
NZXT Kraken X63 RGB使用了尺寸為315mm×143mm×30mm的鋁制水冷排，同樣采用了純白配色，可以搭配2個140mm風(fēng)扇使用，四周采用了包邊設(shè)計。一共有14條冷排水道，水道之間的鰭片采用折片設(shè)計，整體做工比較細(xì)致。水冷管是長度400mm的橡膠管道，管外包裹著細(xì)尼龍編制網(wǎng)套，減少了水管被劃傷的幾率，水冷頭端支持30°旋轉(zhuǎn)微調(diào)膠管方向，防止與其他硬件的碰撞沖突。
冷排上配備了2把Aer RGB 2 140風(fēng)扇，扇葉周圍框架上有RGB燈環(huán)，同樣可以通過CAM軟件控制燈效。風(fēng)扇搭載了FDB液態(tài)軸承，在扇葉邊緣采用了倒角進(jìn)氣口，主打耐用和靜音。風(fēng)扇轉(zhuǎn)速為500~1500RPM（±300RPM），擁有最大91.19 CFM的風(fēng)量表現(xiàn)，在轉(zhuǎn)速不變的情況下，最大風(fēng)量上要比Aer RGB 2 120風(fēng)扇好上太多，這使得280水冷的風(fēng)扇能以更低的轉(zhuǎn)速運(yùn)行，相較于240水冷擁有比較明顯的靜音優(yōu)勢。
扣具方面，NZXT Kraken X63 RGB的平臺兼容性非常不錯，主流以及發(fā)燒平臺基本能做到全覆蓋，玩家可以根據(jù)自己使用的平臺進(jìn)行選擇。另外，現(xiàn)在購買產(chǎn)品的用戶向賣家提供購買憑證以及SN號碼，就能免費(fèi)領(lǐng)取Intel LGA1700主板扣具，準(zhǔn)備升級12代處理器的用戶可以繼續(xù)使用這款水冷。
為了測試這款水冷的散熱性能，我們將NZXT Kraken X63 RGB安裝在一個i9-12900K搭建的英特爾12代測試平臺，使用AIDA64只勾選FPU壓力測試以獲得最大且穩(wěn)定的處理器發(fā)熱量，進(jìn)行為時20分鐘的考機(jī)溫度測試。在NZXT CAM軟件中提供了靜音、性能、固定和自定義四種散熱模式，不過這只影響日常使用時的風(fēng)扇調(diào)度，CPU滿載情況下的性能是一樣的。
測試時，我們手動將風(fēng)扇和水泵轉(zhuǎn)速拉到最大，在室溫為23.8℃的辦公室中，考機(jī)20分鐘CPU封裝溫度為90℃，此時CPU功耗在240W左右，其中P核、E核分別穩(wěn)定在4.9GHz和3.7GHz。通過NZXT的CAM控制軟件，可以看到這時候水冷液的溫度為32℃，也是很低的溫度水平，說明積熱基本都被排出去了，滿載狀態(tài)下的散熱及噪聲表現(xiàn)都比較不錯。而在默認(rèn)的靜音模式下，它的靜音效果完全和240水冷拉開了差距，運(yùn)行時幾乎聽不到風(fēng)聲，并且在這個轉(zhuǎn)速下140風(fēng)扇也能輕松吹透冷排，待機(jī)溫度僅為28℃。
總結(jié)：有顏有實(shí)力的冷靜之選
今年NZXT的水冷相比以前要更加強(qiáng)調(diào)提升外觀視覺效果，比如我們今天測評的KRAKEN X63 RGB就是一款純白配色并且搭載RGB燈光的一體式水冷，顏值方面非常出眾。而作為一款280水冷散熱器，它有著相對360水冷更強(qiáng)的兼容性，同時產(chǎn)品的散熱和靜音表現(xiàn)不俗，在性能測試下能將i9-12900K這樣的旗艦處理器的溫度控制在90℃，如果搭配定位稍低的12代i7、i5處理器使用基本能滿足其散熱需求。同時原廠提供六年質(zhì)保，質(zhì)量方面不用擔(dān)心，有興趣的小伙伴可以了解一下。
RPM：對RPM格式的軟件包進(jìn)行安裝、查詢、更新、升級、校驗(yàn)、卸載以及生成.rpm格式的軟件包等。
YUM：能在線下載、安裝、卸載、升級rpm軟件包等任務(wù)，并且能夠自動查找并解決rpm包之間的依賴關(guān)系，一次性完成所有具有依賴關(guān)系rpm包的安裝。
一、RPM管理工具
二、YUM管理工具
三、總結(jié)
四、思維導(dǎo)圖