给RPM打包的软件加补丁

　　%Patch0: %{name}-2.2.6.patch这一行告诉 RPM 第一个补丁文件名。 如果有必要，可以添加 %Patch1、 %Patch2等。

　　在 %prep部分中的 %patch -p1行是一个 RPM 宏， 它将在您系统的构建目录中运行补丁程序，其中把第一个补丁文件作为输入。 需要将 -p1传递给补丁程序，告诉它从补丁文件中的路径中剥去一层目录，因为该补丁文件包含 indent-2.2.6目录名，而 RPM 将在该目录内运行该补丁文件。

　　通过示例学习

　　既然，您理解了有关如何构建 RPM 包的基础知识，则可以通过研究一些示例来学习更多的知识。 最好的源代码示例之一是您自己的 Linux 分发版。例如，RedHat 带有包含源 RPM 包的整张 CD。 以下是如何使用它们。

　　源 RPM 包包含：

　　一个 .spec 文件

　　一个或多个源文件

　　所有使用过的补丁文件

　　与安装二进制 RPM 包类似，可以使用 rpm -i filename.rpm安装源 RPM 包。 安装完之后，.spec 文件将在您的 %_specdir 目录中，源文件和补丁文件将在您的 %_sourcedir 目录中。 如果创建了上面描述的 .rpmmacros 文件，那么这些目录为 ~/rpm/SPECS 和 ~/rpm/SOURCES。

　　现在，可以读取 Red Hat 自己分发的这些包的 .spec 文件。 可以尝试用 rpm -ba foo.spec构建这些 .spec 文件，并观察所发生的事情，以及摆弄 spec 文件以尝试一些新的事物。

　　对于 GNU indent 程序，一个好的方法是从 Red Hat 的源 RPM 包开始。看一下您是否可以想出为什么它们的 .spec 文件不同于本文中的 .spec 文件。

　　二进制 RPM 包的可移植性

　　不幸的是，二进制 RPM 包在可移植性方面不是很好。多数情况下，构建在某个 Linux 分发版上的 RPM 不能应用到另一个 Linux 分发版。 更不要说应用到同一个分发版的另一个版本上！

　　原因有很多，包括基本内核版本、库版本和目录结构方面的差异。

　　这很不幸，但象 Linux Standard Base这样的组织正在尝试达到分发版之间的一致， 以解决难以移植的问题。也许有一天，构建在一个主流 Linux 分发版上的任何 RPM 都可以安装和运行在相同的处理器之上的任何 其它主流 Linux 分发版上。

　　至于现在，您应该做好计划，有多少个 RPM 将要在其上运行的分发版，就可能构建有多少个 RPM，或者寻找志愿者来为您完成这件事。

　　分发您的工作结果：tar 文件和源 RPM 包

　　为了使其他人在尽可能多的分发版上构建您的软件，就要使 .spec 文件和补丁文件成为可用的文件。

　　如果有必要，最好的方法是直接更改软件，所以该方法将在 Linux 上进行构建，并将 .spec 文件包含在分发版中。 如果 .spec 文件在带有源码的 tar 压缩包（.tar.gz 文件）中，那么用户只需运行：

　　rpm -tb foo.tar.gz

　　并构建该包的二进制 RPM ― 甚至无需解压该 tar 文件!

　　如果无法使 .spec 文件包含在软件中，则可以分发一个源 RPM 包。 有了这，用户就可以运行：

　　rpm --rebuild foo.src.rpm

　　并在他们的系统上构建二进制 RPM。