也许，Fedora 社区追求其促进自由和开源的软件及内容的使命的最著名的方式就是开发 Fedora 软件发行版了。因此，我们将很大一部分的社区资源用于此任务也就不足为奇了。这篇文章总结了这些软件是如何“打包”的，以及使之成为可能的基础工具，如 rpm 之类。

RPM：最小的软件单元

可供用户选择的“版本”和“风味版”（spins / labs / silverblue）其实非常相似。它们都是由各种软件组成的，这些软件经过混合和搭配，可以很好地协同工作。它们之间的不同之处在于放入其中的具体工具不同。这种选择取决于它们所针对的用例。所有这些的“版本”和“风味版”基本组成单位都是 RPM 软件包文件。

RPM 文件是类似于 ZIP 文件或 tarball 的存档文件。实际上，它们使用了压缩来减小存档文件的大小。但是，除了文件之外，RPM 存档中还包含有关软件包的元数据。可以使用 rpm 工具查询：

$ rpm -q fpaste
fpaste-0.3.9.2-2.fc30.noarch

$ rpm -qi fpaste
Name        : fpaste
Version     : 0.3.9.2
Release     : 2.fc30
Architecture: noarch
Install Date: Tue 26 Mar 2019 08:49:10 GMT
Group       : Unspecified
Size        : 64144
License     : GPLv3+
Signature   : RSA/SHA256, Thu 07 Feb 2019 15:46:11 GMT, Key ID ef3c111fcfc659b9
Source RPM  : fpaste-0.3.9.2-2.fc30.src.rpm
Build Date  : Thu 31 Jan 2019 20:06:01 GMT
Build Host  : buildhw-07.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : https://pagure.io/fpaste
Bug URL     : https://bugz.fedoraproject.org/fpaste
Summary     : A simple tool for pasting info onto sticky notes instances
Description :
It is often useful to be able to easily paste text to the Fedora
Pastebin at http://paste.fedoraproject.org and this simple script
will do that and return the resulting URL so that people may
examine the output. This can hopefully help folks who are for
some reason stuck without X, working remotely, or any other
reason they may be unable to paste something into the pastebin

$ rpm -ql fpaste
/usr/bin/fpaste
/usr/share/doc/fpaste
/usr/share/doc/fpaste/README.rst
/usr/share/doc/fpaste/TODO
/usr/share/licenses/fpaste
/usr/share/licenses/fpaste/COPYING
/usr/share/man/man1/fpaste.1.gz

安装 RPM 软件包后，rpm 工具可以知道具体哪些文件被添加到了系统中。因此，删除该软件包也会删除这些文件，并使系统保持一致状态。这就是为什么要尽可能地使用 rpm 安装软件，而不是从源代码安装软件的原因。

依赖关系

如今，完全独立的软件已经非常罕见。甚至 fpaste，连这样一个简单的单个文件的 Python 脚本，都需要安装 Python 解释器。因此，如果系统未安装 Python（几乎不可能，但有可能），则无法使用 fpaste。用打包者的术语来说，“Python 是 fpaste 的运行时依赖项。”

构建 RPM 软件包时（本文不讨论构建 RPM 的过程），生成的归档文件中包括了所有这些元数据。这样，与 RPM 软件包归档文件交互的工具就知道必须要安装其它的什么东西，以便 fpaste 可以正常工作：

$ rpm -q --requires fpaste
/usr/bin/python3
python3
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1

$ rpm -q --provides fpaste
fpaste = 0.3.9.2-2.fc30

$ rpm -qi python3
Name        : python3
Version     : 3.7.3
Release     : 3.fc30
Architecture: x86_64
Install Date: Thu 16 May 2019 18:51:41 BST
Group       : Unspecified
Size        : 46139
License     : Python
Signature   : RSA/SHA256, Sat 11 May 2019 17:02:44 BST, Key ID ef3c111fcfc659b9
Source RPM  : python3-3.7.3-3.fc30.src.rpm
Build Date  : Sat 11 May 2019 01:47:35 BST
Build Host  : buildhw-05.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : https://www.python.org/
Bug URL     : https://bugz.fedoraproject.org/python3
Summary     : Interpreter of the Python programming language
Description :
Python is an accessible, high-level, dynamically typed, interpreted programming
language, designed with an emphasis on code readability.
It includes an extensive standard library, and has a vast ecosystem of
third-party libraries.

The python3 package provides the "python3" executable: the reference
interpreter for the Python language, version 3.
The majority of its standard library is provided in the python3-libs package,
which should be installed automatically along with python3.
The remaining parts of the Python standard library are broken out into the
python3-tkinter and python3-test packages, which may need to be installed
separately.

Documentation for Python is provided in the python3-docs package.

Packages containing additional libraries for Python are generally named with
the "python3-" prefix.

$ rpm -q --provides python3
python(abi) = 3.7
python3 = 3.7.3-3.fc30
python3(x86-64) = 3.7.3-3.fc30
python3.7 = 3.7.3-3.fc30
python37 = 3.7.3-3.fc30

解决 RPM 依赖关系

虽然 rpm 知道每个归档文件所需的依赖关系，但不知道在哪里找到它们。这是设计使然：rpm 仅适用于本地文件，必须具体告知它们的位置。因此，如果你尝试安装单个 RPM 软件包，则 rpm 找不到该软件包的运行时依赖项时就会出错。本示例尝试安装从 Fedora 软件包集中下载的软件包：

$ ls
python3-elephant-0.6.2-3.fc30.noarch.rpm

$ rpm -qpi python3-elephant-0.6.2-3.fc30.noarch.rpm
Name        : python3-elephant
Version     : 0.6.2
Release     : 3.fc30
Architecture: noarch
Install Date: (not installed)
Group       : Unspecified
Size        : 2574456
License     : BSD
Signature   : (none)
Source RPM  : python-elephant-0.6.2-3.fc30.src.rpm
Build Date  : Fri 14 Jun 2019 17:23:48 BST
Build Host  : buildhw-02.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : http://neuralensemble.org/elephant
Bug URL     : https://bugz.fedoraproject.org/python-elephant
Summary     : Elephant is a package for analysis of electrophysiology data in Python
Description :
Elephant - Electrophysiology Analysis Toolkit Elephant is a package for the
analysis of neurophysiology data, based on Neo.

$ rpm -qp --requires python3-elephant-0.6.2-3.fc30.noarch.rpm
python(abi) = 3.7
python3.7dist(neo) >= 0.7.1
python3.7dist(numpy) >= 1.8.2
python3.7dist(quantities) >= 0.10.1
python3.7dist(scipy) >= 0.14.0
python3.7dist(six) >= 1.10.0
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1

$ sudo rpm -i ./python3-elephant-0.6.2-3.fc30.noarch.rpm
error: Failed dependencies:
        python3.7dist(neo) >= 0.7.1 is needed by python3-elephant-0.6.2-3.fc30.noarch
        python3.7dist(quantities) >= 0.10.1 is needed by python3-elephant-0.6.2-3.fc30.noarch

理论上，你可以下载 python3-elephant 所需的所有软件包，并告诉 rpm 它们都在哪里，但这并不方便。如果 python3-neo 和 python3-quantities 还有其它的运行时要求怎么办？很快，这种“依赖链”就会变得相当复杂。

存储库

幸运的是，有了 dnf 和它的朋友们，可以帮助解决此问题。与 rpm 不同，dnf 能感知到存储库。存储库是程序包的集合，带有告诉 dnf 这些存储库包含什么内容的元数据。所有 Fedora 系统都带有默认启用的默认 Fedora 存储库：

$ sudo dnf repolist
repo id              repo name                             status
fedora               Fedora 30 - x86_64                    56,582
fedora-modular       Fedora Modular 30 - x86_64               135
updates              Fedora 30 - x86_64 - Updates           8,573
updates-modular      Fedora Modular 30 - x86_64 - Updates     138
updates-testing      Fedora 30 - x86_64 - Test Updates      8,458

在 Fedora 快速文档中有这些存储库以及如何管理它们的更多信息。

dnf 可用于查询存储库以获取有关它们包含的软件包信息。它还可以在这些存储库中搜索软件，或从中安装/卸载/升级软件包：

$ sudo dnf search elephant
Last metadata expiration check: 0:05:21 ago on Sun 23 Jun 2019 14:33:38 BST.
============================================================================== Name & Summary Matched: elephant ==============================================================================
python3-elephant.noarch : Elephant is a package for analysis of electrophysiology data in Python
python3-elephant.noarch : Elephant is a package for analysis of electrophysiology data in Python

$ sudo dnf list \*elephant\*
Last metadata expiration check: 0:05:26 ago on Sun 23 Jun 2019 14:33:38 BST.
Available Packages
python3-elephant.noarch      0.6.2-3.fc30      updates-testing
python3-elephant.noarch      0.6.2-3.fc30              updates

安装依赖项

现在使用 dnf 安装软件包时，它将解决所有必需的依赖项，然后调用 rpm 执行该事务操作：

$ sudo dnf install python3-elephant
Last metadata expiration check: 0:06:17 ago on Sun 23 Jun 2019 14:33:38 BST.
Dependencies resolved.
==============================================================================================================================================================================================
 Package                                      Architecture                     Version                                                        Repository                                 Size
==============================================================================================================================================================================================
Installing:
 python3-elephant                             noarch                           0.6.2-3.fc30                                                   updates-testing                           456 k
Installing dependencies:
 python3-neo                                  noarch                           0.8.0-0.1.20190215git49b6041.fc30                              fedora                                    753 k
 python3-quantities                           noarch                           0.12.2-4.fc30                                                  fedora                                    163 k
Installing weak dependencies:
 python3-igor                                 noarch                           0.3-5.20150408git2c2a79d.fc30                                  fedora                                     63 k

Transaction Summary
==============================================================================================================================================================================================
Install  4 Packages

Total download size: 1.4 M
Installed size: 7.0 M
Is this ok [y/N]: y
Downloading Packages:
(1/4): python3-igor-0.3-5.20150408git2c2a79d.fc30.noarch.rpm                                                                                                  222 kB/s |  63 kB     00:00
(2/4): python3-elephant-0.6.2-3.fc30.noarch.rpm                                                                                                               681 kB/s | 456 kB     00:00
(3/4): python3-quantities-0.12.2-4.fc30.noarch.rpm                                                                                                            421 kB/s | 163 kB     00:00
(4/4): python3-neo-0.8.0-0.1.20190215git49b6041.fc30.noarch.rpm                                                                                               840 kB/s | 753 kB     00:00
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                                                                         884 kB/s | 1.4 MB     00:01
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                                                                                                                      1/1
  Installing       : python3-quantities-0.12.2-4.fc30.noarch                                                                                                                              1/4
  Installing       : python3-igor-0.3-5.20150408git2c2a79d.fc30.noarch                                                                                                                    2/4
  Installing       : python3-neo-0.8.0-0.1.20190215git49b6041.fc30.noarch                                                                                                                 3/4
  Installing       : python3-elephant-0.6.2-3.fc30.noarch                                                                                                                                 4/4
  Running scriptlet: python3-elephant-0.6.2-3.fc30.noarch                                                                                                                                 4/4
  Verifying        : python3-elephant-0.6.2-3.fc30.noarch                                                                                                                                 1/4
  Verifying        : python3-igor-0.3-5.20150408git2c2a79d.fc30.noarch                                                                                                                    2/4
  Verifying        : python3-neo-0.8.0-0.1.20190215git49b6041.fc30.noarch                                                                                                                 3/4
  Verifying        : python3-quantities-0.12.2-4.fc30.noarch                                                                                                                              4/4

Installed:
  python3-elephant-0.6.2-3.fc30.noarch   python3-igor-0.3-5.20150408git2c2a79d.fc30.noarch   python3-neo-0.8.0-0.1.20190215git49b6041.fc30.noarch   python3-quantities-0.12.2-4.fc30.noarch

Complete!

请注意，dnf 甚至还安装了python3-igor，而它不是 python3-elephant 的直接依赖项。

DnfDragora：DNF 的一个图形界面

尽管技术用户可能会发现 dnf 易于使用，但并非所有人都这样认为。Dnfdragora 通过为 dnf 提供图形化前端来解决此问题。

从上面可以看到，dnfdragora 似乎提供了 dnf 的所有主要功能。

Fedora 中还有其他工具也可以管理软件包，GNOME 的“ 软件 Software ”和“ 发现 Discover ”就是其中两个。GNOME “软件”仅专注于图形应用程序。你无法使用这个图形化前端来安装命令行或终端工具，例如 htop 或 weechat。但是，GNOME “软件”支持安装 dnf 所不支持的 Flatpak 和 Snap 应用程序。它们是针对不同目标受众的不同工具，因此提供了不同的功能。

这篇文章仅触及到了 Fedora 软件的生命周期的冰山一角。本文介绍了什么是 RPM 软件包，以及使用 rpm 和 dnf 的主要区别。

在以后的文章中，我们将详细介绍：

• 创建这些程序包所需的过程
• 社区如何测试它们以确保它们正确构建
• 社区用来将其给到社区用户的基础设施

via: https://fedoramagazine.org/rpm-packages-explained/

作者：Ankur Sinha FranciscoD 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

节省跨多个主机安装文件和脚本的时间和精力。

自20多年前我开始使用 Linux 以来，我已经使用过基于 rpm 的软件包管理器在 Red Hat 和 Fedora Linux 系统上安装软件。我使用过 rpm 程序本身，还有 yum 和 dnf ，用于在我的 Linux 主机上安装和更新软件包，dnf 是 yum 的一个近亲。 yum 和 dnf 工具是 rpm 实用程序的包装器，它提供了其他功能，例如查找和安装包依赖项的功能。

多年来，我创建了许多 Bash 脚本，其中一些脚本具有单独的配置文件，我希望在大多数新计算机和虚拟机上安装这些脚本。这也能解决安装所有这些软件包需要花费大量时间的难题，因此我决定通过创建一个 rpm 软件包来自动执行该过程，我可以将其复制到目标主机并将所有这些文件安装在适当的位置。虽然 rpm 工具以前用于构建 rpm 包，但该功能已被删除，并且创建了一个新工具来构建新的 rpm。

当我开始这个项目时，我发现很少有关于创建 rpm 包的信息，但我找到了一本书，名为《Maximum RPM》，这本书才帮我弄明白了。这本书现在已经过时了，我发现的绝大多数信息都是如此。它也已经绝版，用过的副本也需要花费数百美元。Maximum RPM 的在线版本是免费提供的，并保持最新。该 RPM 网站还有其他网站的链接，这些网站上有很多关于 rpm 的文档。其他的信息往往是简短的，显然都是假设你已经对该过程有了很多了解。

此外，我发现的每个文档都假定代码需要在开发环境中从源代码编译。我不是开发人员。我是一个系统管理员，我们系统管理员有不同的需求，因为我们不需要或者我们不应该为了管理任务而去编译代码；我们应该使用 shell 脚本。所以我们没有源代码，因为它需要被编译成二进制可执行文件。我们拥有的源代码也应该是可执行的。

在大多数情况下，此项目应作为非 root 用户执行。 rpm 包永远不应该由 root 用户构建，而只能由非特权普通用户构建。我将指出哪些部分应该以 root 身份执行，哪些部分应由非 root，非特权用户执行。

准备

首先，打开一个终端会话，然后 su 到 root 用户。 请务必使用 - 选项以确保启用完整的 root 环境。 我不认为系统管理员应该使用 sudo 来执行任何管理任务。 在我的个人博客文章中可以找出为什么：真正的系统管理员不要使用 sudo。

[student@testvm1 ~]$ su -
Password:
[root@testvm1 ~]#

创建可用于此项目的普通用户 student，并为该用户设置密码。

[root@testvm1 ~]# useradd -c "Student User" student
[root@testvm1 ~]# passwd student
Changing password for user student.
New password: <Enter the password>
Retype new password: <Enter the password>
passwd: all authentication tokens updated successfully.
[root@testvm1 ~]#

构建 rpm 包需要 rpm-build 包，该包可能尚未安装。 现在以 root 身份安装它。 请注意，此命令还将安装多个依赖项。 数量可能会有所不同，具体取决于主机上已安装的软件包； 它在我的测试虚拟机上总共安装了 17 个软件包，这是非常小的。

dnf install -y rpm-build

除非另有明确指示，否则本项目的剩余部分应以普通用户用户 student 来执行。 打开另一个终端会话并使用 su 切换到该用户以执行其余步骤。 使用以下命令从 GitHub 下载我准备好的开发目录结构 utils.tar 这个 tar 包 tarball （LCTT 译注：tarball 是以 tar 命令来打包和压缩的文件的统称）：

wget https://github.com/opensourceway/how-to-rpm/raw/master/utils.tar

此 tar 包包含将由最终 rpm 程序安装的所有文件和 Bash 脚本。 还有一个完整的 spec 文件，你可以使用它来构建 rpm。 我们将详细介绍 spec 文件的每个部分。

作为普通学生 student，使用你的家目录作为当前工作目录（pwd），解压缩 tar 包。

[student@testvm1 ~]$ cd ; tar -xvf utils.tar

使用 tree 命令验证 ~/development 的目录结构和包含的文件，如下所示：

[student@testvm1 ~]$ tree development/
development/
├── license
│   ├── Copyright.and.GPL.Notice.txt
│   └── GPL_LICENSE.txt
├── scripts
│   ├── create_motd
│   ├── die
│   ├── mymotd
│   └── sysdata
└── spec
    └── utils.spec

3 directories, 7 files
[student@testvm1 ~]$

mymotd 脚本创建一个发送到标准输出的“当日消息”数据流。 create_motd 脚本运行 mymotd 脚本并将输出重定向到 /etc/motd 文件。 此文件用于向使用 SSH 远程登录的用户显示每日消息。

die 脚本是我自己的脚本，它将 kill 命令包装在一些代码中，这些代码可以找到与指定字符串匹配的运行程序并将其终止。 它使用 kill -9 来确保 kill 命令一定会执行。

sysdata 脚本可以显示有关计算机硬件，还有已安装的 Linux 版本，所有已安装的软件包以及硬盘驱动器元数据等数万行数据。 我用它来记录某个时间点的主机状态。 我以后可以用它作为参考。 我曾经这样做是为了维护我为客户安装的主机记录。

你可能需要将这些文件和目录的所有权更改为 student:student 。 如有必要，使用以下命令执行此操作：

chown -R student:student development

此文件树中的大多数文件和目录将通过你在此项目期间创建的 rpm 包安装在 Fedora 系统上。

创建构建目录结构

rpmbuild 命令需要非常特定的目录结构。 你必须自己创建此目录结构，因为没有提供自动方式。 在家目录中创建以下目录结构：

~ ─ rpmbuild
    ├── RPMS
    │   └── noarch
    ├── SOURCES
    ├── SPECS
    └── SRPMS

我们不会创建 rpmbuild/RPMS/X86_64 目录，因为它是特定于体系结构编译的 64 位二进制文件。 我们有 shell 脚本，不是特定于体系结构的。 实际上，我们也不会使用 SRPMS 目录，它将包含编译器的源文件。

检查 spec 文件

每个 spec 文件都有许多部分，其中一些部分可能会被忽视或省略，取决于 rpm 构建的具体情况。 这个特定的 spec 文件不是工作所需的最小文件的示例，但它是一个包含不需要编译的文件的中等复杂 spec 文件的很好例子。 如果需要编译，它将在 %build 部分中执行，该部分在此 spec 文件中省略掉了，因为它不是必需的。

前言

这是 spec 文件中唯一没有标签的部分。 它包含运行命令 rpm -qi [Package Name] 时看到的大部分信息。 每个数据都是一行，由标签和标签值的文本数据组成。

###############################################################################
# Spec file for utils
################################################################################
# Configured to be built by user student or other non-root user
################################################################################
#
Summary: Utility scripts for testing RPM creation
Name: utils
Version: 1.0.0
Release: 1
License: GPL
URL: http://www.both.org
Group: System
Packager: David Both
Requires: bash
Requires: screen
Requires: mc
Requires: dmidecode
BuildRoot: ~/rpmbuild/

# Build with the following syntax:
# rpmbuild --target noarch -bb utils.spec

rpmbuild 程序会忽略注释行。我总是喜欢在本节中添加注释，其中包含创建包所需的 rpmbuild 命令的确切语法。

Summary 标签是包的简短描述。

Name、Version 和 Release 标签用于创建 rpm 文件的名称，如 utils-1.00-1.rpm。通过增加发行版号码和版本号，你可以创建 rpm 包去更新旧版本的。

License 标签定义了发布包的许可证。我总是使用 GPL 的一个变体。指定许可证对于澄清包中包含的软件是开源的这一事实非常重要。这也是我将 License 和 GPL 语句包含在将要安装的文件中的原因。

URL 通常是项目或项目所有者的网页。在这种情况下，它是我的个人网页。

Group 标签很有趣，通常用于 GUI 应用程序。 Group 标签的值决定了应用程序菜单中的哪一组图标将包含此包中可执行文件的图标。与 Icon 标签（我们此处未使用）一起使用时，Group 标签允许在应用程序菜单结构中添加用于启动程序的图标和所需信息。

Packager 标签用于指定负责维护和创建包的人员或组织。

Requires 语句定义此 rpm 包的依赖项。每个都是包名。如果其中一个指定的软件包不存在，DNF 安装实用程序将尝试在 /etc/yum.repos.d 中定义的某个已定义的存储库中找到它，如果存在则安装它。如果 DNF 找不到一个或多个所需的包，它将抛出一个错误，指出哪些包丢失并终止。

BuildRoot 行指定顶级目录，rpmbuild 工具将在其中找到 spec 文件，并在构建包时在其中创建临时目录。完成的包将存储在我们之前指定的 noarch 子目录中。

注释显示了构建此程序包的命令语法，包括定义了目标体系结构的 –target noarch 选项。因为这些是 Bash 脚本，所以它们与特定的 CPU 架构无关。如果省略此选项，则构建将选用正在执行构建的 CPU 的体系结构。

rpmbuild 程序可以针对许多不同的体系结构，并且使用 --target 选项允许我们在不同的体系结构主机上构建特定体系结构的包，其具有与执行构建的体系结构不同的体系结构。所以我可以在 x86\_64 主机上构建一个用于 i686 架构的软件包，反之亦然。

如果你有自己的网站，请将打包者的名称更改为你自己的网站。

描述部分（%description）

spec 文件的 %description 部分包含 rpm 包的描述。 它可以很短，也可以包含许多信息。 我们的 %description 部分相当简洁。

%description
A collection of utility scripts for testing RPM creation.

准备部分（%prep）

%prep 部分是在构建过程中执行的第一个脚本。 在安装程序包期间不会执行此脚本。

这个脚本只是一个 Bash shell 脚本。 它准备构建目录，根据需要创建用于构建的目录，并将相应的文件复制到各自的目录中。 这将包括作为构建的一部分的完整编译所需的源代码。

$RPM_BUILD_ROOT 目录表示已安装系统的根目录。 在 $RPM_BUILD_ROOT 目录中创建的目录是真实文件系统中的绝对路径，例如 /user/local/share/utils、/usr/local/bin 等。

对于我们的包，我们没有预编译源，因为我们的所有程序都是 Bash 脚本。 因此，我们只需将这些脚本和其他文件复制到已安装系统的目录中。

%prep
################################################################################
# Create the build tree and copy the files from the development directories    #
# into the build tree.                                                         #
################################################################################
echo "BUILDROOT = $RPM_BUILD_ROOT"
mkdir -p $RPM_BUILD_ROOT/usr/local/bin/
mkdir -p $RPM_BUILD_ROOT/usr/local/share/utils

cp /home/student/development/utils/scripts/* $RPM_BUILD_ROOT/usr/local/bin
cp /home/student/development/utils/license/* $RPM_BUILD_ROOT/usr/local/share/utils
cp /home/student/development/utils/spec/* $RPM_BUILD_ROOT/usr/local/share/utils

exit

请注意，本节末尾的 exit 语句是必需的。

文件部分（%files）

spec 文件的 %files 这一部分定义了要安装的文件及其在目录树中的位置。 它还指定了要安装的每个文件的文件属性（%attr）以及所有者和组所有者。 文件权限和所有权是可选的，但我建议明确设置它们以消除这些属性在安装时不正确或不明确的任何可能性。 如果目录尚不存在，则会在安装期间根据需要创建目录。

%files
%attr(0744, root, root) /usr/local/bin/*
%attr(0644, root, root) /usr/local/share/utils/*

安装前（%pre）

在我们的实验室项目的 spec 文件中，此部分为空。 这应该放置那些需要 rpm 中的文件安装前执行的脚本。

安装后（%post）

spec 文件的这一部分是另一个 Bash 脚本。 这个在文件安装后运行。 此部分几乎可以是你需要或想要的任何内容，包括创建文件、运行系统命令以及重新启动服务以在进行配置更改后重新初始化它们。 我们的 rpm 包的 %post 脚本执行其中一些任务。

%post
################################################################################
# Set up MOTD scripts                                                          #
################################################################################
cd /etc
# Save the old MOTD if it exists
if [ -e motd ]
then
   cp motd motd.orig
fi
# If not there already, Add link to create_motd to cron.daily
cd /etc/cron.daily
if [ ! -e create_motd ]
then
   ln -s /usr/local/bin/create_motd
fi
# create the MOTD for the first time
/usr/local/bin/mymotd > /etc/motd

此脚本中包含的注释应明确其用途。

卸载后（%postun）

此部分包含将在卸载 rpm 软件包后运行的脚本。 使用 rpm 或 dnf 删除包会删除文件部分中列出的所有文件，但它不会删除安装后部分创建的文件或链接，因此我们需要在本节中处理。

此脚本通常由清理任务组成，只是清除以前由 rpm 安装的文件，但 rpm 本身无法完成清除。 对于我们的包，它包括删除 %post 脚本创建的链接并恢复 motd 文件的已保存原件。

%postun
# remove installed files and links
rm /etc/cron.daily/create_motd

# Restore the original MOTD if it was backed up
if [ -e /etc/motd.orig ]
then
   mv -f /etc/motd.orig /etc/motd
fi

清理（%clean）

这个 Bash 脚本在 rpm 构建过程之后开始清理。 下面 %clean 部分中的两行删除了 rpm-build 命令创建的构建目录。 在许多情况下，可能还需要额外的清理。

%clean
rm -rf $RPM_BUILD_ROOT/usr/local/bin
rm -rf $RPM_BUILD_ROOT/usr/local/share/utils

变更日志（%changelog）

此可选的文本部分包含 rpm 及其包含的文件的变更列表。最新的变更记录在本部分顶部。

%changelog
* Wed Aug 29 2018 Your Name <[email protected]>
  - The original package includes several useful scripts. it is
    primarily intended to be used to illustrate the process of
    building an RPM.

使用你自己的姓名和电子邮件地址替换标题行中的数据。

构建 rpm

spec 文件必须位于 rpmbuild 目录树的 SPECS 目录中。 我发现最简单的方法是创建一个指向该目录中实际 spec 文件的链接，以便可以在开发目录中对其进行编辑，而无需将其复制到 SPECS 目录。 将 SPECS 目录设为当前工作目录，然后创建链接。

cd ~/rpmbuild/SPECS/
ln -s ~/development/spec/utils.spec

运行以下命令以构建 rpm。 如果没有错误发生，只需要花一点时间来创建 rpm。

rpmbuild --target noarch -bb utils.spec

检查 ~/rpmbuild/RPMS/noarch 目录以验证新的 rpm 是否存在。

[student@testvm1 ~]$ cd rpmbuild/RPMS/noarch/
[student@testvm1 noarch]$ ll
total 24
-rw-rw-r--. 1 student student 24364 Aug 30 10:00 utils-1.0.0-1.noarch.rpm
[student@testvm1 noarch]$

测试 rpm

以 root 用户身份安装 rpm 以验证它是否正确安装并且文件是否安装在正确的目录中。 rpm 的确切名称将取决于你在前言部分中标签的值，但如果你使用了示例中的值，则 rpm 名称将如下面的示例命令所示：

[root@testvm1 ~]# cd /home/student/rpmbuild/RPMS/noarch/
[root@testvm1 noarch]# ll
total 24
-rw-rw-r--. 1 student student 24364 Aug 30 10:00 utils-1.0.0-1.noarch.rpm
[root@testvm1 noarch]# rpm -ivh utils-1.0.0-1.noarch.rpm
Preparing...                          ################################# [100%]
Updating / installing...
   1:utils-1.0.0-1                    ################################# [100%]

检查 /usr/local/bin 以确保新文件存在。 你还应验证是否已创建 /etc/cron.daily 中的 create_motd 链接。

使用 rpm -q --changelog utils 命令查看更改日志。 使用 rpm -ql utils 命令（在 ql 中为小写 L ）查看程序包安装的文件。

[root@testvm1 noarch]# rpm -q --changelog utils
* Wed Aug 29 2018 Your Name <[email protected]>
- The original package includes several useful scripts. it is
    primarily intended to be used to illustrate the process of
    building an RPM.

[root@testvm1 noarch]# rpm -ql utils
/usr/local/bin/create_motd
/usr/local/bin/die
/usr/local/bin/mymotd
/usr/local/bin/sysdata
/usr/local/share/utils/Copyright.and.GPL.Notice.txt
/usr/local/share/utils/GPL_LICENSE.txt
/usr/local/share/utils/utils.spec
[root@testvm1 noarch]#

删除包。

rpm -e utils

试验

现在，你将更改 spec 文件以要求一个不存在的包。 这将模拟无法满足的依赖关系。 在现有依赖行下立即添加以下行：

Requires: badrequire

构建包并尝试安装它。 显示什么消息？

我们使用 rpm 命令来安装和删除 utils 包。 尝试使用 yum 或 dnf 安装软件包。 你必须与程序包位于同一目录中，或指定程序包的完整路径才能使其正常工作。

总结

在这篇对创建 rpm 包的基础知识的概览中，我们没有涉及很多标签和很多部分。 下面列出的资源可以提供更多信息。 构建 rpm 包并不困难；你只需要正确的信息。 我希望这对你有所帮助——我花了几个月的时间来自己解决问题。

我们没有涵盖源代码构建，但如果你是开发人员，那么从这一点开始应该是一个简单的步骤。

创建 rpm 包是另一种成为懒惰系统管理员的好方法，可以节省时间和精力。 它提供了一种简单的方法来分发和安装那些我们作为系统管理员需要在许多主机上安装的脚本和其他文件。

资料

• Edward C. Baily，《Maximum RPM》，Sams 出版于 2000 年，ISBN 0-672-31105-4
• Edward C. Baily，《Maximum RPM》，更新在线版本
• RPM 文档：此网页列出了 rpm 的大多数可用在线文档。 它包括许多其他网站的链接和有关 rpm 的信息。

via: https://opensource.com/article/18/9/how-build-rpm-packages

作者：David Both 选题：lujun9972 译者：Flowsnow 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

包管理器在 Linux 软件管理中扮演了重要角色。这里对一些主要的包管理器进行了对比。

今天，每个可计算设备都会使用某种软件来完成预定的任务。在软件开发的上古时期，为了找出软件中的“虫”和其它缺陷，软件会被严格的测试。在近十年间，软件被通过互联网来频繁分发，以试图通过持续不断的安装新版本的软件来解决软件的缺陷问题。在很多情况下，每个独立的应用软件都有其自带的更新器。而其它一些软件则让用户自己去搞明白如何获取和升级软件。

Linux 较早采用了维护一个中心化的软件仓库来发布软件更新这种做法，用户可以在这个软件仓库里查找并安装软件。在这篇文章里， 笔者将回顾在 Linux 上的如何进行软件安装的历史，以及现代操作系统如何保持更新以应对软件安全漏洞（CVE）不断的曝光。

那么在包管理器出现之前在 Linux 上是如何安装软件的呢？

曾几何时，软件都是通过 FTP 或邮件列表（LCTT 译注：即通过邮件列表发布源代码的补丁包）来分发的（最终这些发布方式在互联网的迅猛发展下都演化成为一个个现今常见的软件发布网站）。（一般在一个 tar 文件中）只有一个非常小的文件包含了创建二进制的说明。你需要做的是先解压这个包，然后仔细阅读当中的 README 文件， 如果你的系统上恰好有 GCC（LCTT 译注：GNU C Compiler）或者其它厂商的 C 编译器的话，你得首先运行 ./configure 脚本，并在脚本后添加相应的参数，如库函数的路径、创建可执行文件的路径等等。除此之外，这个配置过程也会检查你操作系统上的软件依赖是否满足安装要求。如果缺失了任何主要的依赖，该配置脚本会退出不再继续安装，直到你满足了该依赖。如果该配置脚本正常执行完毕，将会创建一个 Makefile 文件。

当有了一个 Makefile 文件时， 你就可以接下去执行 make 命令（该命令由你所使用的编译器提供）。make 命令也有很多参数，被称为 make 标识 flag ，这些标识能为你的系统优化最终生成出来的二进制可执行文件。在计算机世界的早期，这些优化是非常重要的，因为彼时的计算机硬件正在为了跟上软件迅速的发展而疲于奔命。今日今时，编译标识变得更加通用而不是为了优化哪些具体的硬件型号，这得益于现代硬件和现代软件相比已经变得成本低廉，唾手可得。

最后，在 make 完成之后， 你需要运行 make install （或 sudo make install）（LCTT 译注：依赖于你的用户权限） 来“真正”将这个软件安装到你的系统上。可以想象，为你系统上的每一个软件都执行上述的流程将是多么无聊费时，更不用说如果更新一个已经安装的软件将会多复杂，多么需要精力投入。（LCTT 译注：上述流程也称 CMMI 安装， 即Configure、Make、Make Install）

那么软件包是什么？

软件包 package （LCTT 译注：下文简称“包”）这个概念是用来解决在软件安装、升级过程中的复杂性的。包将软件安装升级中需要的多个数据文件合并成一个单独的文件，这将便于传输和（通过压缩文件来）减小存储空间（LCTT 译注：减少存储空间这一点在现在已经不再重要），包中的二进制可执行文件已根据开发者所选择的编译标识预编译。包本身包括了所有需要的元数据，如软件的名字、软件的说明、版本号，以及要运行这个软件所需要的依赖包等等。

不同流派的 Linux 发行版都创造了它们自己的包格式，其中最常用的包格式有：

• .deb：这种包格式由 Debian、Ubuntu、Linux Mint 以及其它的变种使用。这是最早被发明的包类型。
• .rpm：这种包格式最初被称作 红帽包管理器 Red Hat Package Manager （LCTT 译注： 取自英文的首字母）。使用这种包的 Linux 发行版有 Red Hat、Fedora、SUSE 以及其它一些较小的发行版。
• .tar.xz：这种包格式只是一个软件压缩包而已，这是 Arch Linux 所使用的格式。

尽管上述的包格式自身并不能直接管理软件的依赖问题，但是它们的出现将 Linux 软件包管理向前推进了一大步。

软件仓库到底是什么？

多年以前（当智能电话还没有像现在这样流行时），非 Linux 世界的用户是很难理解软件仓库的概念的。甚至今时今日，大多数完全工作在 Windows 下的用户还是习惯于打开浏览器，搜索要安装的软件（或升级包），下载然后安装。但是，智能电话传播了软件“商店”（LCTT 译注： 对应 Linux 里的软件仓库）这样一个概念。智能电话用户获取软件的方式和包管理器的工作方式已经非常相近了。些许不同的是，尽管大多数软件商店还在费力美化它的图形界面来吸引用户，大多数 Linux 用户还是愿意使用命令行来安装软件。总而言之，软件仓库是一个中心化的可安装软件列表，上面列举了在当前系统中预先配置好的软件仓库里所有可以安装的软件。下面我们举一些例子来说在各个不同的 Linux 发行版下如何在对应的软件仓库里搜寻某个特定的软件（输出有截断）。

在 Arch Linux 下使用 aurman：

user@arch ~ $  aurman -Ss kate

extra/kate 18.04.2-2 (kde-applications kdebase)
    Advanced Text Editor
aur/kate-root 18.04.0-1 (11, 1.139399)
    Advanced Text Editor, patched to be able to run as root
aur/kate-git r15288.15d26a7-1 (1, 1e-06)
    An advanced editor component which is used in numerous KDE applications requiring a text editing component

在 CentOS 7 下使用 yum：

[user@centos ~]$ yum search kate

kate-devel.x86_64 : Development files for kate
kate-libs.x86_64 : Runtime files for kate
kate-part.x86_64 : Kate kpart plugin

在 Ubuntu 下使用 apt：

user@ubuntu ~ $ apt search kate
Sorting... Done
Full Text Search... Done

kate/xenial 4:15.12.3-0ubuntu2 amd64
  powerful text editor

kate-data/xenial,xenial 4:4.14.3-0ubuntu4 all
  shared data files for Kate text editor

kate-dbg/xenial 4:15.12.3-0ubuntu2 amd64
  debugging symbols for Kate

kate5-data/xenial,xenial 4:15.12.3-0ubuntu2 all
  shared data files for Kate text editor

最好用的包管理器有哪些？

如上示例的输出，包管理器用来和相应的软件仓库交互，获取软件的相应信息。下面对它们做一个简短介绍。

基于 PRM 包格式的包管理器

更新基于 RPM 的系统，特别是那些基于 Red Hat 技术的系统，有着非常有趣而又详实的历史。实际上，现在的 YUM) 版本（用于 企业级发行版）和 DNF（用于社区版）就融合了好几个开源项目来提供它们现在的功能。

Red Hat 最初使用的包管理器，被称为 RPM)（ 红帽包管理器 Red Hat Package Manager ），时至今日还在使用着。不过，它的主要作用是安装本地的 RPM 包，而不是去在软件仓库搜索软件。后来开发了一个叫 up2date 的包管理器，它被用来通知用户包的最新更新，还能让用户在远程仓库里搜索软件并便捷的安装软件的依赖。尽管这个包管理器尽职尽责，但一些社区成员还是感觉 up2date 有着明显的不足。

现在的 YUM 来自于好几个不同社区的努力。1999-2001 年一群在 Terra Soft Solution 的伙计们开发了 黄狗更新器 Yellowdog Updater （YUP），将其作为 Yellow Dog Linux 图形安装器的后端。 杜克大学 Duke University 喜欢这个主意就决定去增强它的功能，它们开发了 黄狗更新器--修改版 Yellowdog Updater, Modified （YUM），这最终被用来帮助管理杜克大学的 Red Hat 系统。Yum 壮大的很快，到 2005 年，它已经被超过一半的 Linux 市场所采用。今日，几乎所有的使用 RPM 的的 Linux 都会使用 YUM 来进行包管理（当然也有一些例外）。

使用 YUM

为了能让 YUM 正常工作，比如从一个软件仓库里下载和安装包，仓库说明文件必须放在 /etc/yum.repos.d/ 目录下且必须以 .repo 作为扩展名。如下是一个示例文件的内容：

[local_base]
name=Base CentOS  (local)
baseurl=http://7-repo.apps.home.local/yum-repo/7/
enabled=1
gpgcheck=0

这是笔者本地仓库之一，这也是为什么 gpgcheck 值为 0 的原因。如果这个值为 1 的话，每个包都需要被密钥签名，相应的密钥（的公钥）也要导入到安装软件的系统上。因为这个软件仓库是笔者本人维护的且笔者信任这个仓库里的包，所以就不去对它们一一签名了。

当一个仓库文件准备好时，你就能开始从远程软件仓库开始安装文件了。最基本的命令是 yum update，这将会更新所有已安装的包。你也不需要用特殊的命令来更新仓库本身，所有这一切都已自动完成了。运行命令示例如下：

[user@centos ~]$ sudo yum update
Loaded plugins: fastestmirror, product-id, search-disabled-repos, subscription-manager
local_base                             | 3.6 kB  00:00:00    
local_epel                             | 2.9 kB  00:00:00    
local_rpm_forge                        | 1.9 kB  00:00:00    
local_updates                          | 3.4 kB  00:00:00    
spideroak-one-stable                   | 2.9 kB  00:00:00    
zfs                                    | 2.9 kB  00:00:00    
(1/6): local_base/group_gz             | 166 kB  00:00:00    
(2/6): local_updates/primary_db        | 2.7 MB  00:00:00    
(3/6): local_base/primary_db           | 5.9 MB  00:00:00    
(4/6): spideroak-one-stable/primary_db |  12 kB  00:00:00    
(5/6): local_epel/primary_db           | 6.3 MB  00:00:00    
(6/6): zfs/x86_64/primary_db           |  78 kB  00:00:00    
local_rpm_forge/primary_db             | 125 kB  00:00:00    
Determining fastest mirrors
Resolving Dependencies
--> Running transaction check

如果你确定想让 YUM 在执行任何命令时不要停下来等待用户输入，你可以命令里放 -y 标志，如 yum update -y。

安装一个新包很简单。首先，用 yum search 搜索包的名字。

[user@centos ~]$ yum search kate

artwiz-aleczapka-kates-fonts.noarch : Kates font in Artwiz family
ghc-highlighting-kate-devel.x86_64 : Haskell highlighting-kate library development files
kate-devel.i686 : Development files for kate
kate-devel.x86_64 : Development files for kate
kate-libs.i686 : Runtime files for kate
kate-libs.x86_64 : Runtime files for kate
kate-part.i686 : Kate kpart plugin

当你找到你要安装的包后，你可以用 sudo yum install kate-devel -y 来安装。如果你安装了你不需要的软件，可以用 sudo yum remove kdate-devel -y 来从系统上删除它，默认情况下，YUM 会删除软件包以及它的依赖。

有些时候你甚至都不清楚要安装的包的名称，你只知道某个实用程序的名字。（LCTT 译注：可以理解实用程序是安装包的子集）。例如，你想找实用程序 updatedb（它是用来创建/更新由 locate 命令所使用的数据库的），直接试图安装 updatedb 会返回下面的结果：

[user@centos ~]$ sudo yum install updatedb
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
No package updatedb available.
Error: Nothing to do

你可以搜索实用程序来自哪个包：

[user@centos ~]$ yum whatprovides *updatedb
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile

bacula-director-5.2.13-23.1.el7.x86_64 : Bacula Director files
Repo        : local_base
Matched from:
Filename    : /usr/share/doc/bacula-director-5.2.13/updatedb

mlocate-0.26-8.el7.x86_64 : An utility for finding files by name
Repo        : local_base
Matched from:
Filename    : /usr/bin/updatedb

笔者在前面使用星号的原因是 yum whatprovides 使用路径去匹配文件。笔者不确定文件在哪里，所以使用星号去指代任意路径。

当然 YUM 还有很多其它的可选项。这里笔者希望你能够自己查看 YUM 的手册来找到其它额外的可选项。

时髦的 Yum Dandified Yum （DNF）是 YUM 的下一代接班人。从 Fedora 18 开始被作为包管理器引入系统，不过它并没有被企业版所采用，所以它只在 Fedora（以及变种）上占据了主导地位。DNF 的用法和 YUM 几乎一模一样，它主要是用来解决性能问题、晦涩无说明的API、缓慢/不可靠的依赖解析，以及偶尔的高内存占用。DNF 是作为 YUM 的直接替代品来开发的，因此这里笔者就不重复它的用法了，你只用简单的将 yum 替换为 dnf 就行了。

使用 Zypper

Zypper 是用来管理 RPM 包的另外一个包管理器。这个包管理器主要用于 SUSE（和 openSUSE），在MeeGo、Sailfish OS、Tizen 上也有使用。它最初开发于 2006 年，已经经过了多次迭代。除了作为系统管理工具 YaST 的后端和有些用户认为它比 YUM 要快之外也没有什么好多说的。

Zypper 使用与 YUM 非常相像。它被用来搜索、更新、安装和删除包，简单的使用命令如下：

zypper search kate
zypper update
zypper install kate
zypper remove kate

主要的不同来自于使用 Zypper 的系统在添加软件仓库的做法上，Zypper 使用包管理器本身来添加软件仓库。最通用的方法是通过一个 URL，但是 Zypper 也支持从仓库文件里导入。

suse:~ # zypper addrepo http://download.videolan.org/pub/vlc/SuSE/15.0 vlc
Adding repository 'vlc' [done]
Repository 'vlc' successfully added

Enabled     : Yes
Autorefresh : No
GPG Check   : Yes
URI         : http://download.videolan.org/pub/vlc/SuSE/15.0
Priority    : 99

你也能用相似的手段来删除软件仓库：

suse:~ # zypper removerepo vlc
Removing repository 'vlc' ...................................[done]
Repository 'vlc' has been removed.

使用 zypper repos 命令来查看当前系统上的软件仓库的状态：

suse:~ # zypper repos
Repository priorities are without effect. All enabled repositories share the same priority.

#  | Alias                     | Name                                    | Enabled | GPG Check | Refresh
---|---------------------------|-----------------------------------------|---------|-----------|--------
 1 | repo-debug                | openSUSE-Leap-15.0-Debug                | No      | ----      | ----  
 2 | repo-debug-non-oss        | openSUSE-Leap-15.0-Debug-Non-Oss        | No      | ----      | ----  
 3 | repo-debug-update         | openSUSE-Leap-15.0-Update-Debug         | No      | ----      | ----  
 4 | repo-debug-update-non-oss | openSUSE-Leap-15.0-Update-Debug-Non-Oss | No      | ----      | ----  
 5 | repo-non-oss              | openSUSE-Leap-15.0-Non-Oss              | Yes     | ( p) Yes  | Yes    
 6 | repo-oss                  | openSUSE-Leap-15.0-Oss                  | Yes     | ( p) Yes  | Yes    

zypper 甚至还有和 YUM 相同的功能：搜索包含文件或二进制的包。和 YUM 有所不同的是，它在命令行里使用破折号（但是这个搜索方法现在被废除了……）

localhost:~ # zypper what-provides kate
Command 'what-provides' is replaced by 'search --provides --match-exact'.
See 'help search' for all available options.
Loading repository data...
Reading installed packages...

S  | Name | Summary              | Type      
---|------|----------------------|------------
i+ | Kate | Advanced Text Editor | application
i  | kate | Advanced Text Editor | package  

YUM、DNF 和 Zypper 三剑客拥有的功能比在这篇小文里讨论的要多得多，请查看官方文档来得到更深入的信息。

基于 Debian 的包管理器

作为一个现今仍在被积极维护的最古老的 Linux 发行版之一，Debian 的包管理系统和基于 RPM 的系统的包管理系统非常类似。它使用扩展名为 “.deb” 的包，这种文件能被一个叫做 dpkg 的工具所管理。dpgk 同 rpm 非常相似，它被设计成用来管理在存在于本地（硬盘）的包。它不会去做包依赖关系解析（它会做依赖关系检查，不过仅此而已），而且在同远程软件仓库交互上也并无可靠的途径。为了提高用户体验并便于使用，Debian 项目开始了一个软件项目：Deity，最终这个代号被丢弃并改成了现在的 高级打包工具 Advanced Pack Tool （APT）。

在 1998 年，APT 测试版本发布（甚至早于 1999 年的 Debian 2.1 发布），许多用户认为 APT 是基于 Debian 系统标配功能之一。APT 使用了和 RPM 一样的风格来管理仓库，不过和 YUM 使用单独的 .repo 文件不同，APT 曾经使用 /etc/apt/sources.list 文件来管理软件仓库，后来的变成也可以使用 /etc/apt/sources.d 目录来管理。如同基于 RPM 的系统一样，你也有很多很多选项配置来完成同样的事情。你可以编辑和创建前述的文件，或者使用图形界面来完成上述工作（如 Ubuntu 的“Software & Updates”），为了给所有的 Linux 发行版统一的待遇，笔者将会只介绍命令行的选项。 要想不直接编辑文件内容而直接增加软件仓库的话，可以用如下命令：

user@ubuntu:~$ sudo apt-add-repository "deb http://APT.spideroak.com/ubuntu-spideroak-hardy/ release restricted"

这个命令将会在 /etc/apt/sources.list.d 目录里创建一个 spideroakone.list 文件。显而易见，文件里的内容依赖于所添加的软件仓库，如果你想加一个 个人软件包存档 Personal Package Archive （PPA）的话，你可以用如下的办法：

user@ubuntu:~$ sudo apt-add-repository ppa:gnome-desktop

注意： Debian 原生并不支持本地 PPA 。

在添加了一个软件仓库后，需要通知基于 Debian 的系统有一个新的仓库可以用来搜索包，可以运行 apt-get update 来完成：

user@ubuntu:~$ sudo apt-get update
Get:1 http://security.ubuntu.com/ubuntu xenial-security InRelease [107 kB]
Hit:2 http://APT.spideroak.com/ubuntu-spideroak-hardy release InRelease
Hit:3 http://ca.archive.ubuntu.com/ubuntu xenial InRelease
Get:4 http://ca.archive.ubuntu.com/ubuntu xenial-updates InRelease [109 kB]              
Get:5 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages [517 kB]
Get:6 http://security.ubuntu.com/ubuntu xenial-security/main i386 Packages [455 kB]      
Get:7 http://security.ubuntu.com/ubuntu xenial-security/main Translation-en [221 kB]    
...

Fetched 6,399 kB in 3s (2,017 kB/s)                                          
Reading package lists... Done

现在新的软件仓库已经在你的系统里安装并更新好了，你可以用 apt-cache 来搜索你想要的包了。

user@ubuntu:~$ apt-cache search kate
aterm-ml - Afterstep XVT - a VT102 emulator for the X window system
frescobaldi - Qt4 LilyPond sheet music editor
gitit - Wiki engine backed by a git or darcs filestore
jedit - Plugin-based editor for programmers
kate - powerful text editor
kate-data - shared data files for Kate text editor
kate-dbg - debugging symbols for Kate
katepart - embeddable text editor component

要安装 kate，简单的运行下面的命令：

user@ubuntu:~$ sudo apt-get install kate

要是删除一个包，使用 apt-get remove：

user@ubuntu:~$ sudo apt-get remove kate

要探索一个包的话，APT 并没有提供一个类似于 yum whatprovides 的功能，如果你想深入包内部去确定一个特定的文件的话，也有一些别的方法能帮你完成这个目标，

如： 用 dpkg

user@ubuntu:~$ dpkg -S /bin/ls
coreutils: /bin/ls

或者： apt-file

user@ubuntu:~$ sudo apt-get install apt-file -y
user@ubuntu:~$ sudo apt-file update
user@ubuntu:~$ apt-file search kate

与 yum whatprovides 不同的是，apt-file search 的问题是因为自动添加了通配符搜索而输出过于详细（除非你知道确切的路径），最终在结果里包括了所有包含有 “kate” 的结果。

kate: /usr/bin/kate
kate: /usr/lib/x86_64-linux-gnu/qt5/plugins/ktexteditor/katebacktracebrowserplugin.so
kate: /usr/lib/x86_64-linux-gnu/qt5/plugins/ktexteditor/katebuildplugin.so
kate: /usr/lib/x86_64-linux-gnu/qt5/plugins/ktexteditor/katecloseexceptplugin.so
kate: /usr/lib/x86_64-linux-gnu/qt5/plugins/ktexteditor/katectagsplugin.so

上面这些例子大部分都使用了 apt-get。请注意现今大多数的 Ubuntu 教程里都径直使用了 apt。 单独一个 apt 设计用来实现那些最常用的 APT 命令的。apt 命令看上去是用来整合那些被分散在 apt-get、apt-cache 以及其它一些命令的的功能的。它还加上了一些额外的改进，如色彩、进度条以及其它一些小功能。上述的常用命令都能被 apt 替代，但是并不是所有的基于 Debian 的系统都能使用 apt 接受安全包补丁的，你有可能要安装额外的包的实现上述功能。

基于 Arch 的包管理器

Arch Linux 使用称为 packman 的包管理器。和 .deb 以及 .rpm 不同，它使用更为传统的 LZMA2 压缩包形式 .tar.xz 。这可以使 Arch Linux 包能够比其它形式的压缩包（如 gzip）有更小的尺寸。自从 2002 年首次发布以来， pacman 一直在稳定发布和改善。使用它最大的好处之一是它支持 Arch Build System，这是一个从源代码级别构建包的构建系统。该构建系统借助一个叫 PKGBUILD 的文件，这个文件包含了如版本号、发布号、依赖等等的元数据，以及一个为编译遵守 Arch Linux 需求的包所需要的带有必要的编译选项的脚本。而编译的结果就是前文所提的被 pacman 所使用的 .tar.xz 的文件。

上述的这套系统技术上导致了 Arch 用户仓库 Arch User Respository （AUR）的产生，这是一个社区驱动的软件仓库，仓库里包括有 PKGBUILD 文件以及支持补丁或脚本。这给 Arch Linux 带了无穷无尽的软件资源。最为明显的好处是如果一个用户（或开发者）希望他开发的软件能被广大公众所使用，他不必通过官方途径去在主流软件仓库获得许可。而不利之处则是它必须将依赖社区的流程，类似于 Docker Hub、 Canonical 的 Snap Packages（LCTT 译注： Canonical 是 Ubuntu 的发行公司），或者其它类似的机制。有很多特定于 AUR 的包管理器能被用来从 AUR 里的 PGKBUILD 文件下载、编译、安装，下面我们来仔细看看怎么做。

使用 pacman 和官方软件仓库

Arch 的主要包管理器：pacman，使用标识位而不是像 yum 或 apt 一样使用命令词。例如，要搜索一个包，你要用 pacman -Ss 。和 Linux 上别的命令一样，你可以找到 pacman 的手册页和在线帮助。pacman 大多数的命令都使用了同步（-S）这个标识位。例如：

user@arch ~ $ pacman -Ss kate

extra/kate 18.04.2-2 (kde-applications kdebase)
    Advanced Text Editor
extra/libkate 0.4.1-6 [installed]
    A karaoke and text codec for embedding in ogg
extra/libtiger 0.3.4-5 [installed]
    A rendering library for Kate streams using Pango and Cairo
extra/ttf-cheapskate 2.0-12
    TTFonts collection from dustimo.com
community/haskell-cheapskate 0.1.1-100
    Experimental markdown processor.

Arch 也使用和别的包管理器类似的软件仓库。在上面的输出中，搜索结果前面有标明它是从哪个仓库里搜索到的（这里是 extra/ 和 community/）。同 Red Hat 和 Debian 系统一样，Arch 依靠用户将软件仓库的信息加入到一个特定的文件里：/etc/pacman.conf。下面的例子非常接近一个仓库系统。笔者还打开了 [multilib] 仓库来支持 Steam：

[options]
Architecture = auto

Color
CheckSpace

SigLevel    = Required DatabaseOptional
LocalFileSigLevel = Optional

[core]
Include = /etc/pacman.d/mirrorlist

[extra]
Include = /etc/pacman.d/mirrorlist

[community]
Include = /etc/pacman.d/mirrorlist

[multilib]
Include = /etc/pacman.d/mirrorlist

你也可以在 pacman.conf 里指定具体的 URL。这个功能可以用来确保在某一时刻所有的包来自一个确定的地方，比如，如果一个安装包存在严重的功能缺陷并且很不幸它恰好还有几个包依赖，你能及时回滚到一个安全点，如果你已经在 pacman.conf 里加入了具体的 URL 的话，你就用用这个命令降级你的系统。

[core]
Server=https://archive.archlinux.org/repos/2017/12/22/$repo/os/$arch

和 Debian 系统一样，Arch 并不会自动更新它的本地仓库。你可以用下面的命令来刷新包管理器的数据库：

user@arch ~ $ sudo pacman -Sy

:: Synchronizing package databases...
 core                                                                     130.2 KiB   851K/s 00:00 [##########################################################] 100%
 extra                                                                   1645.3 KiB  2.69M/s 00:01 [##########################################################] 100%
 community                                                                  4.5 MiB  2.27M/s 00:02 [##########################################################] 100%
 multilib is up to date

你可以看到在上述的输出中，pacman 认为 multilib 包数据库是更新到最新状态的。如果你认为这个结果不正确的话，你可以强制运行刷新：pacman -Syy。如果你想升级你的整个系统的话（不包括从 AUR 安装的包），你可以运行 pacman -Syu：

user@arch ~ $ sudo pacman -Syu

:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
 multilib is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...

Packages (45) ceph-13.2.0-2  ceph-libs-13.2.0-2  debootstrap-1.0.105-1  guile-2.2.4-1  harfbuzz-1.8.2-1  harfbuzz-icu-1.8.2-1  haskell-aeson-1.3.1.1-20
              haskell-attoparsec-0.13.2.2-24  haskell-tagged-0.8.6-1  imagemagick-7.0.8.4-1  lib32-harfbuzz-1.8.2-1  lib32-libgusb-0.3.0-1  lib32-systemd-239.0-1
              libgit2-1:0.27.2-1  libinput-1.11.2-1  libmagick-7.0.8.4-1  libmagick6-6.9.10.4-1  libopenshot-0.2.0-1  libopenshot-audio-0.1.6-1  libosinfo-1.2.0-1
              libxfce4util-4.13.2-1  minetest-0.4.17.1-1  minetest-common-0.4.17.1-1  mlt-6.10.0-1  mlt-python-bindings-6.10.0-1  ndctl-61.1-1  netctl-1.17-1
              nodejs-10.6.0-1  

Total Download Size:      2.66 MiB
Total Installed Size:   879.15 MiB
Net Upgrade Size:      -365.27 MiB

:: Proceed with installation? [Y/n]

在前面提到的降级系统的情景中，你可以运行 pacman -Syyuu 来强行降级系统。你必须重视这一点：虽然在大多数情况下这不会引起问题，但是这种可能性还是存在，即降级一个包或几个包将会引起级联传播的失败并会将你的系统处于不一致的状态（LCTT 译注：即系统进入无法正常使用的状态），请务必小心！

运行 pacman -S kate 来安装一个包。

user@arch ~ $ sudo pacman -S kate

resolving dependencies...
looking for conflicting packages...

Packages (7) editorconfig-core-c-0.12.2-1  kactivities-5.47.0-1  kparts-5.47.0-1  ktexteditor-5.47.0-2  syntax-highlighting-5.47.0-1  threadweaver-5.47.0-1
             kate-18.04.2-2

Total Download Size:   10.94 MiB
Total Installed Size:  38.91 MiB

:: Proceed with installation? [Y/n]

你可以运行 pacman -R kate 来删除一个包。这将会只删除这个包自身而不会去删除它的依赖包。

user@arch ~ $ sudo pacman -S kate

checking dependencies...

Packages (1) kate-18.04.2-2

Total Removed Size:  20.30 MiB

:: Do you want to remove these packages? [Y/n]

如果你想删除没有被其它包依赖的包，你可以运行 pacman -Rs：

user@arch ~ $ sudo pacman -Rs kate

checking dependencies...

Packages (7) editorconfig-core-c-0.12.2-1  kactivities-5.47.0-1  kparts-5.47.0-1  ktexteditor-5.47.0-2  syntax-highlighting-5.47.0-1  threadweaver-5.47.0-1
             kate-18.04.2-2

Total Removed Size:  38.91 MiB

:: Do you want to remove these packages? [Y/n]

在笔者看来，Pacman 是搜索一个指定实用程序中的包名的最齐全的工具。如上所示，YUM 和 APT 都依赖于‘路径’去搜索到有用的结果，而 Pacman 则做了一些智能的猜测，它会去猜测你最有可能想搜索的包。

user@arch ~ $ sudo pacman -Fs updatedb
core/mlocate 0.26.git.20170220-1
    usr/bin/updatedb

user@arch ~ $ sudo pacman -Fs kate
extra/kate 18.04.2-2
    usr/bin/kate

使用 AUR

有很多流行的 AUR 包管理器助手。其中 yaourt 和 pacaur 颇为流行。不过，这两个项目已经被 Arch Wiki 列为“不继续开发以及有已知的问题未解决”。因为这个原因，这里直接讨论 aurman，除了会搜索 AUR 以及包含几个有帮助的（其实很危险）的选项之外，它的工作机制和 pacman 极其类似。从 AUR 安装一个包将会初始化包维护者的构建脚本。你将会被要求输入几次授权以便让程序继续进行下去（为了简短起见，笔者截断了输出）。

aurman -S telegram-desktop-bin
~~ initializing aurman...
~~ the following packages are neither in known repos nor in the aur
...
~~ calculating solutions...

:: The following 1 package(s) are getting updated:
   aur/telegram-desktop-bin  1.3.0-1  ->  1.3.9-1

?? Do you want to continue? Y/n: Y

~~ looking for new pkgbuilds and fetching them...
Cloning into 'telegram-desktop-bin'...

remote: Counting objects: 301, done.
remote: Compressing objects: 100% (152/152), done.
remote: Total 301 (delta 161), reused 286 (delta 147)
Receiving objects: 100% (301/301), 76.17 KiB | 639.00 KiB/s, done.
Resolving deltas: 100% (161/161), done.
?? Do you want to see the changes of telegram-desktop-bin? N/y: N

[sudo] password for user:

...
==> Leaving fakeroot environment.
==> Finished making: telegram-desktop-bin 1.3.9-1 (Thu 05 Jul 2018 11:22:02 AM EDT)
==> Cleaning up...
loading packages...
resolving dependencies...
looking for conflicting packages...

Packages (1) telegram-desktop-bin-1.3.9-1

Total Installed Size:  88.81 MiB
Net Upgrade Size:       5.33 MiB

:: Proceed with installation? [Y/n]

依照你所安装的包的复杂性程度的高低，有时你将会被要求给出进一步的输入，为了避免这些反复的输入，aurman 允许你使用 --noconfirm 和 --noedit 选项。这相当于说“接受所有的预定设置，并相信包管理器不会干坏事”。使用这两个选项时请务必小心！！，虽然这些选项本身不太会破坏你的系统，你也不能盲目的接受他人的脚本程序。

总结

这篇文章当然只能触及包管理器的皮毛。还有很多别的包管理器笔者没有在这篇文章里谈及。有些 Linux 发布版，如 Ubuntu 或 Elementary OS，已经在图形版的包管理器的开发上有了长远的进展。

如果你对包管理器的更高级功能有进一步的兴趣，请在评论区留言，笔者很乐意进一步的写一写相关的文章。

附录

# search for packages
yum search <package>
dnf search <package>
zypper search <package>
apt-cache search <package>
apt search <package>
pacman -Ss <package>

# install packages
yum install <package>
dnf install <package>
zypper install <package>
apt-get install <package>
apt install <package>
pacman -Ss <package>

# update package database, not required by yum, dnf and zypper
apt-get update
apt update
pacman -Sy

# update all system packages
yum update
dnf update
zypper update
apt-get upgrade
apt upgrade
pacman -Su

# remove an installed package
yum remove <package>
dnf remove <package>
apt-get remove <package>
apt remove <package>
pacman -R <package>
pacman -Rs <package>

# search for the package name containing specific file or folder
yum whatprovides *<binary>
dnf whatprovides *<binary>
zypper what-provides <binary>
zypper search --provides <binary>
apt-file search <binary>
pacman -Sf <binary>

via: https://opensource.com/article/18/7/evolution-package-managers

作者：Steve Ovens 选题：lujun9972 译者：DavidChenLiang 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

在早先的教程中，我们讨论了如何使用 ISO 镜像和在线 Yum 仓库的方式来创建自己的 Yum 仓库 。创建自己的 Yum 仓库是一个不错的想法，但若网络中只有 2-3 台 Linux 机器那就没啥必要了。不过若你的网络中有大量的 Linux 服务器，而且这些服务器还需要定时进行升级，或者你有大量服务器无法直接访问互联网，那么创建自己的 Yum 仓库就很有必要了。

当我们有大量的 Linux 服务器，而每个服务器都直接从互联网上升级系统时，数据消耗会很可观。为了节省数据量，我们可以创建个离线 Yum 源并将之分享到本地网络中。网络中的其他 Linux 机器就可以直接从本地 Yum 上获取系统更新，从而节省数据量，而且传输速度也会很好。

我们可以使用下面两种方法来分享 Yum 仓库：

• 使用 Web 服务器（Apache）
• 使用 FTP 服务器（VSFTPD）

在开始讲解这两个方法之前，我们需要先根据之前的教程创建一个 Yum 仓库。

使用 Web 服务器

首先在 Yum 服务器上安装 Web 服务器（Apache），我们假设服务器 IP 是 192.168.1.100。我们已经在这台系统上配置好了 Yum 仓库，现在我们来使用 yum 命令安装 Apache Web 服务器，

$ yum install httpd

下一步，拷贝所有的 rpm 包到默认的 Apache 根目录下，即 /var/www/html，由于我们已经将包都拷贝到了 /YUM 下，我们也可以创建一个软连接来从 /var/www/html 指向 /YUM。

$ ln -s /var/www/html/Centos /YUM

重启 Web 服务器应用改变：

$ systemctl restart httpd

配置客户端机器

服务端的配置就完成了，现在需要配置下客户端来从我们创建的离线 Yum 中获取升级包，这里假设客户端 IP 为 192.168.1.101。

在 /etc/yum.repos.d 目录中创建 offline-yum.repo 文件，输入如下信息，

$ vi /etc/yum.repos.d/offline-yum.repo

name=Local YUM
baseurl=http://192.168.1.100/CentOS/7
gpgcheck=0
enabled=1

客户端也配置完了。试一下用 yum 来安装/升级软件包来确认仓库是正常工作的。

使用 FTP 服务器

在 FTP 上分享 Yum，首先需要安装所需要的软件包，即 vsftpd。

$ yum install vsftpd

vsftp 的默认根目录为 /var/ftp/pub，因此你可以拷贝 rpm 包到这个目录，或者为它创建一个软连接：

$ ln -s /var/ftp/pub /YUM

重启服务应用改变：

$ systemctl restart vsftpd

配置客户端机器

像上面一样，在 /etc/yum.repos.d 中创建 offline-yum.repo 文件，并输入下面信息，

$ vi /etc/yum.repos.d/offline-yum.repo

[Offline YUM]
name=Local YUM
baseurl=ftp://192.168.1.100/pub/CentOS/7
gpgcheck=0
enabled=1

现在客户机可以通过 ftp 接收升级了。要配置 vsftpd 服务器为其他 Linux 系统分享文件，请阅读这篇指南。

这两种方法都很不错，你可以任意选择其中一种方法。有任何疑问或这想说的话，欢迎在下面留言框中留言。

via: http://linuxtechlab.com/offline-yum-repository-for-lan/

作者：Shusain 译者：lujun9972 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

过了这个夏天，我把我的桌面环境迁移到了 i3，这是一个瓦片式窗口管理器。当初，切换到 i3 是一个挑战，因为我必须去处理许多以前 GNOME 帮我处理的事情。其中一件事情就是改变屏幕亮度。 xbacklight 这个在笔记本电脑上改变背光亮度的标准方法，它在我的硬件上不工作了。

最近，我发现一个改变背光亮度的工具 brightlight。我决定去试一下它，它工作在 root 权限下。但是，我发现 brightligh 在 Fedora 下没有 RPM 包。我决定，是在 Fedora 下尝试创建一个包的时候了，并且可以学习怎么去创建一个 RPM 包。

在这篇文章中，我将分享以下的内容：

• 创建 RPM SPEC 文件
• 在 Koji 和 Copr　中构建包
• 使用调试包处理一个问题
• 提交这个包到 Fedora 包集合中

前提条件

在 Fedora 上，我安装了包构建过程中所有步骤涉及到的包。

sudo dnf install fedora-packager fedpkg fedrepo_req copr-cli

创建 RPM SPEC 文件

创建 RPM 包的第一步是去创建 SPEC 文件。这些规范，或者是指令，它告诉 RPM 怎么去构建包。这是告诉 RPM 从包的源代码中创建一个二进制文件。创建 SPEC 文件看上去是整个包处理过程中最难的一部分，并且它的难度取决于项目。

对我而言，幸运的是，brightlight 是一个用 C 写的简单应用程序。维护人员用一个 Makefile 使创建二进制应用程序变得很容易。构建它只是在仓库中简单运行 make 的问题。因此，我现在可以用一个简单的项目去学习 RPM 打包。

查找文档

谷歌搜索 “how to create an RPM package” 有很多结果。我开始使用的是 IBM 的文档。然而，我发现它理解起来非常困难，不知所云（虽然十分详细，它可能适用于复杂的 app）。我也在 Fedora 维基上找到了 创建包 的介绍。这个文档在构建和处理上解释的非常好，但是，我一直困惑于 “怎么去开始呢？”

最终，我找到了 RPM 打包指南，它是大神 Adam Miller 写的。这些介绍非常有帮助，并且包含了三个优秀的示例，它们分别是用 Bash、C 和 Python 编写的程序。这个指南帮我很容易地理解了怎么去构建一个 RPM SPEC，并且，更重要的是，解释了怎么把这些片断拼到一起。

有了这些之后，我可以去写 brightlight 程序的我的 第一个 SPEC 文件 了。因为它是很简单的，SPEC 很短也很容易理解。我有了 SPEC 文件之后，我发现其中有一些错误。处理掉一些错误之后，我创建了源 RPM (SRPM) 和二进制 RPM，然后，我解决了出现的每个问题。

rpmlint SPECS/brightlight.spec
rpmbuild -bs SPECS/brightlight.spec
rpmlint SRPMS/brightlight-5-1.fc26.src.rpm
rpmbuild -bb SPECS/brightlight-5-1.fc26.x86_64.rpm
rpmlint RPMS/x86_64/brightlight-5-1.fc26.x86_64.rpm

现在，我有了一个可用的 RPM，可以发送到 Fedora 仓库了。

在 Copr 和 Koji 中构建

接下来，我读了该 指南 中关于怎么成为一个 Fedora 打包者。在提交之前，他们鼓励打包者通过在在 Koji 中托管、并在 Copr 中构建项目来测试要提交的包。

使用 Copr

首先，我为 brightlight 创建了一个 Copr 仓库，Copr 是在 Fedora 的基础设施中的一个服务，它构建你的包，并且为你任意选择的 Fedora 或 EPEL 版本创建一个定制仓库。它对于快速托管你的 RPM 包，并与其它人去分享是非常方便的。你不需要特别操心如何去托管一个 Copr 仓库。

我从 Web 界面创建了我的 Copr 项目，但是，你也可以使用 copr-cli 工具。在 Fedora 开发者网站上有一个 非常优秀的指南。在该网站上创建了我的仓库之后，我使用这个命令构建了我的包。

copr-cli build brightlight SRPMS/brightlight.5-1.fc26.src.rpm

我的包在 Corp 上成功构建，并且，我可以很容易地在我的 Fedora 系统上成功安装它。

使用 Koji

任何人都可以使用 Koji 在多种架构和 Fedora 或 CentOS/RHEL 版本上测试他们的包。在 Koji 中测试，你必须有一个源 RPM。我希望 brightlight 包在 Fedora 所有的版本中都支持，因此，我运行如下的命令：

koji build --scratch f25 SRPMS/brightlight-5-1.fc26.src.rpm
koji build --scratch f26 SRPMS/brightlight-5-1.fc26.src.rpm
koji build --scratch f27 SRPMS/brightlight-5-1.fc26.src.rpm

它花费了一些时间，但是，Koji 构建了所有的包。我的包可以很完美地运行在 Fedora 25 和 26 中，但是 Fedora 27 失败了。 Koji 模拟构建可以使我走在正确的路线上，并且确保我的包构建成功。

问题：Fedora 27 构建失败！

现在，我已经知道我的 Fedora 27 上的包在 Koji 上构建失败了。但是，为什么呢？我发现在 Fedora 27 上有两个相关的变化。

• Subpackage and Source Debuginfo
• RPM 4.14 (特别是，debuginfo 包重写了)

这些变化意味着 RPM 包必须使用一个 debuginfo 包去构建。这有助于排错或调试一个应用程序。在我的案例中，这并不是关键的或者很必要的，但是，我需要去构建一个。

感谢 Igor Gnatenko，他帮我理解了为什么我在 Fedora 27 上构建包时需要去将这些增加到我的包的 SPEC 中。在 %make_build 宏指令之前，我增加了这些行。

export CFLAGS="%{optflags}"
export LDFLAGS="%{__global_ldflags}"

我构建了一个新的 SRPM 并且提交它到 Koji 去在 Fedora 27 上构建。成功了，它构建成功了！

提交这个包

现在，我在 Fedora 25 到 27 上成功校验了我的包，是时候为 Fedora 打包了。第一步是提交这个包，为了请求一个包评估，要在 Red Hat Bugzilla 创建一个新 bug。我为 brightlight 创建了一个工单。因为这是我的第一个包，我明确标注它 “这是我的第一个包”，并且我寻找一个发起人。在工单中，我链接 SPEC 和 SRPM 文件到我的 Git 仓库中。

进入 dist-git

Igor Gnatenko 发起我进入 Fedora 打包者群组，并且在我的包上留下反馈。我学习了一些其它的关于 C 应用程序打包的特定的知识。在他响应我之后，我可以在 dist-git 上申请一个仓库，Fedora 的 RPM 包集合仓库为所有的 Fedora 版本保存了 SPEC 文件。

一个很方便的 Python 工具使得这一部分很容易。fedrepo-req 是一个用于创建一个新的 dist-git 仓库的请求的工具。我用这个命令提交我的请求。

fedrepo-req brightlight \
    --ticket 1505026 \
    --description "CLI tool to change screen back light brightness" \
    --upstreamurl https://github.com/multiplexd/brightlight

它为我在 fedora-scm-requests 仓库创建了一个新的工单。这是一个我是管理员的 创建的仓库。现在，我可以开始干了！

My first RPM in Fedora dist-git – woohoo!

与 dist-git 一起工作

接下来，fedpkg 是用于和 dist-git 仓库进行交互的工具。我改变当前目录到我的 git 工作目录，然后运行这个命令。

fedpkg clone brightlight

fedpkg 从 dist-git 克隆了我的包的仓库。对于这个仅有的第一个分支，你需要去导入 SRPM。

fedpkg import SRPMS/brightlight-5-1.fc26.src.rpm

fedpkg 导入你的包的 SRPM 到这个仓库中，然后设置源为你的 Git 仓库。这一步对于使用 fedpkg 是很重要的，因为它用一个 Fedora 友好的方去帮助规范这个仓库（与手动添加文件相比）。一旦你导入了 SRPM，推送这个改变到 dist-git 仓库。

git commit -m "Initial import (#1505026)."
git push

构建包

自从你推送第一个包导入到你的 dist-git 仓库中，你已经准备好了为你的项目做一次真实的 Koji 构建。要构建你的项目，运行这个命令。

fedpkg build

它会在 Koji 中为 Rawhide 构建你的包，这是 Fedora 中的非版本控制的分支。在你为其它分支构建之前，你必须在 Rawhide 分支上构建成功。如果一切构建成功，你现在可以为你的项目的其它分支发送请求了。

fedrepo-req brightlight f27 -t 1505026
fedrepo-req brightlight f26 -t 1505026
fedrepo-req brightlight f25 -t 1505026

关于构建其它分支的注意事项

一旦你最初导入了 SRPM，如果你选择去创建其它分支，记得合并你的主分支到它们。例如，如果你后面为 Fedora 27 请求一个分支，你将需要去使用这些命令。

fedpkg switch-branch f27
git merge master
git push
fedpkg build

提交更新到 Bodhi

这个过程的最后一步是，把你的新包作为一个更新包提交到 Bodhi 中。当你初次提交你的更新包时，它将去测试这个仓库。任何人都可以测试你的包并且增加 karma 到该更新中。如果你的更新接收了 3 个以上的投票（或者像 Bodhi 称它为 karma），你的包将自动被推送到稳定仓库。否则，一周之后，推送到测试仓库中。

要提交你的更新到 Bodhi，你仅需要一个命令。

fedpkg update

它为你的包用一个不同的配置选项打开一个 Vim 窗口。一般情况下，你仅需要去指定一个 类型（比如，newpackage）和一个你的包评估的票据 ID。对于更深入的讲解，在 Fedora 维基上有一篇更新的指南。

在保存和退出这个文件后，fedpkg 会把你的包以一个更新包提交到 Bodhi，最后，同步到 Fedora 测试仓库。我也可以用这个命令去安装我的包。

sudo dnf install brightlight -y --enablerepo=updates-testing --refresh

稳定仓库

最近提交了我的包到 Fedora 26 稳定仓库，并且不久将进入 Fedora 25 和 Fedora 27 稳定仓库。感谢帮助我完成我的第一个包的每个人。我期待有更多的机会为发行版添加包。

via: https://blog.justinwflory.com/2017/11/first-rpm-package-fedora/

作者：JUSTIN W. FLORY 译者：qhwdw 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

你是否想要了解安装包中各个文件在 Linux 系统中安装（位于）的位置？我们将在本文介绍如何列出文件的来源，或存在于某个特定包或者一组软件包中的文件。

这篇文章可以帮你轻松地找到重要的软件包文件，如配置文件、帮助文档等。我们来看看找出文件在哪个包中或者从哪个包中安装的几个方法：

如何列出 Linux 中全部已安装软件包的文件

你可以使用 repoquery 命令，它是 yum-utils 的一部分，用来列出给定的软件包在 CentOS/RHEL 系统上安装的文件。

要安装并使用 yum-utils，运行下面的命令：

# yum update 
# yum install yum-utils

现在你可以列出一个已安装包的文件了，比如 httpd 服务器 （注意包名是大小写敏感的）。--installed 表示已经安装的包，-l 列出所有的文件：

# repoquery --installed -l httpd
# dnf repoquery --installed -l httpd  [On Fedora 22+ versions]

repoquery 列出 httpd 安装的文件

重要：在 Fedora 22 以上的版本中，repoquery 命令在基于 RPM 的发行版中已经与 dnf 包管理器整合，可以用上面的方法列出安装的文件。

除此之外，你也可以使用下面的 rpm 命令列出 .rpm 包中或已经安装的 .rpm 包的文件，下面的 -q 和 -l 表示列出其后跟着的包中的文件：

# rpm -ql httpd

rpm 查询已安装程序的安装包

另外一个有用的建议是使用 -p 在安装之前列出 .rpm 中的文件。

# rpm -qlp telnet-server-1.2-137.1.i586.rpm

在 Debian/Ubuntu 发行版中，你可以使用 dpkg 命令带上 -L 标志在 Debian 系统或其衍生版本中列出给定 .deb 包的安装的文件。

在这个例子中，我们会列出 apache2 Web 服务器安装的文件：

$ dpkg -L apache2

dpkg 列出安装的包

不要忘记查看其它有关在 Linux 中软件包管理的文章。

1. 20 个有用的 yum 包管理命令
2. 20 个有用的 rpm 包管理命令
3. 15 个 Ubuntu 中有用的 apt 包管理命令
4. 15 个 Ubuntu 中有用的 dpkg命令
5. 5 个最佳的对 Linux 新手的包管理器

就是这样了！在本文中，我们向你展示了如何在 Linux 中列出/找到给定的软件包或软件包组安装的所有文件。在下面的评论栏中分享你的想法。

作者简介：

Aaron Kili 是 Linux 和 F.O.S.S 的爱好者，目前任 TecMint 的作者，志向是一名 Linux 系统管理员、web 开发者。他喜欢用电脑工作，并热衷于分享知识。

via: http://www.tecmint.com/list-files-installed-from-rpm-deb-package-in-linux/

作者：Aaron Kili 译者：geekpi 校对：ezio

本文由 LCTT 原创编译，Linux中国 荣誉推出