Next Previous Contents

6. Building RPMs

如果您可以自个儿取得所需的软体,那麽建造 RPM 档案也是非常简单的。

建造 RPM 档案的基本步骤如下:

如果一切操作正确, RPM 便能顺利 build 完成 binary 与 source 程式套件。

6.1 The rpmrc File

目前为止, RPM 系统唯一的设定档, 是透过 /etc/rpmrc 档案来管理。 其内容□例如下:

require_vendor: 1
distribution: I roll my own!
require_distribution: 1
topdir: /usr/src/me
vendor: Mickiesoft
packager:  Mickeysoft Packaging Account <packages@mickiesoft.com>

optflags: i386 -O2 -m486 -fno-strength-reduce
optflags: alpha -O2
optflags: sparc -O2

signature: pgp
pgp_name: Mickeysoft Packaging Account
pgp_path: /home/packages/.pgp

tmppath: /usr/tmp

档案中的 require_vendor 这一行叙述, 用以控制 RPM 是否须要找寻 vendor 那一行叙述, 而 verdor 的资讯可能来自 /etc/rpmrc 或是 spec 档案的 header 处。 如果您把上述的号码改为 0, 便能把这项寻找功能关闭。 这样的设定方式, 同样适用於 require_distributionrequire_group 的叙述上。

接下来, 我们看到 distribution 这一行, 您可以在此设定, 或是日後在 spec 档案的 header 处设定。 当我们在某个 distribution 上 build 程式套件时, 就算不需要查询设定, 此行内容的设定正确, 也是能够带来许多便利。 vendor 那一行的作用, 和上述的 distribution 非常相似, 但其内容并不限定 ( 例如是 Joe's Software 或 Rock Music Emporium )。

RPM 目前支援「多平台架构」的程式套件 build 功能, 我们可以在 rpmrc 档案里指定 ``optflags'' 变数, 当进行程式套件 build 动作时, 便可依据所需的平台类型, 应用特定的变数内容。 我们将会在接下去的章节里, 说明如何使用这些变数。

除了上述的 macro 设定外, 还有许多其他的设定方式, 您可以使用:

rpm --showrc
来查看系统的 tag 与可供使用的 flag 有哪些。

6.2 The Spec File

在此我们将讨论 spec 档案的设定。 build 一个程式套件时, 我们需要使用到 spec 档案, 其内容为该程式套件的说明, 额外还包括一些指令, 用以指示整个 build 的过程, 还有一份档案列表, 用以表示程式套件中的档案, 分别被安装到哪里。

spec 档案的命名方式, 最好是遵循标准的惯例, 其格式应该为 package name-dash-version number-dash-release number-dot-spec。

这里我们举一个小型的 spec 档案为例 (vim-3.0-1.spec):

Summary: ejects ejectable media and controls auto ejection
Name: eject
Version: 1.4
Release: 3
Copyright: GPL
Group: Utilities/System
Source: sunsite.unc.edu:/pub/Linux/utils/disk-management/eject-1.4.tar.gz
Patch: eject-1.4-make.patch
Patch1: eject-1.4-jaz.patch
%description
This program allows the user to eject media that is autoejecting like
CD-ROMs, Jaz and Zip drives, and floppy drives on SPARC machines.

%prep
%setup
%patch -p1
%patch1 -p1

%build
make RPM_OPT_FLAGS="$RPM_OPT_FLAGS"

%install
install -s -m 755 -o 0 -g 0 eject /usr/bin/eject
install -m 644 -o 0 -g 0 eject.1 /usr/man/man1

%files
%doc README COPYING ChangeLog

/usr/bin/eject
/usr/man/man1/eject.1

6.3 The Header

档案 header 的部份, 有几个特定的栏位内容, 您必须加以设定完成, 另外还有几点注意事项。 您必须设定完成的栏位内容如下:

6.4 Prep

这里是 spec 档案的另一个段落章节, 用以设定让 source 档案就绪, 以供下一步的 build 动作。 平常我们必须经过 setup, 才能实际进行 make 动作, 因此在本段落章节中, 我们将视需要进行 source 档案的 patch 与 setup。

有件事值得注意的: 接下来的段落设定, 实际上只是指明某段 shell scripts 的位置, 您可以将 shell scripts 的内容, 另外以 sh script 的方式加以存档, 并将 script 程式名称置於 %prep tag 之後, 用以执行 source 档案的 unpack 与 patch 动作。 当然, 以原有之 macro 型式来做, 应该是方便许多的。

第一个要说明的 macro 是 %setup。 如果我们采用其最简单的格式 ( 即不加任何命令列参数的情况 ), 它会单纯地将 source 档案加以 unpack, 并 cd 进入 source 档案的目录。 除此之外, 您还可以使用下列的选项:

接下来要说明的 macro 是 %patch。 它是用来协助自动处理 source 档案更新的动作, 其相关的选项很多, 列表说明如下:

这些应该就是全部所需要知道之 macro 说明, 了解它们之後, 您也可以透过 sh 之 script 格式, 设定不同的 setup 方法, 在 %build macro ( 在下一章节中会提及 ) 之前, 您所设定之所有选项, 都是经由 sh 来执行, 您可以再参考一下前述的□例, 或许可以适用於您的需要。

6.5 Build

这个章节里, 所述及的并非真正的 macro。 当您把 source 档案 untar, 并且 patch 完成, cd 进入目录之後, 开始准备 build 动作时, 便是在这里设定那些控制 build 动作的指令。 而这些指令都还是传给 sh, 所以任何 sh 之指令, 都可以在此指定 ( 包括 comments 在内 )。 在 spec 档案里的每一段落章节设定中, 您的目前所在目录位置, 都会被重新设定为 source directory 的最上层, 所以请牢记在心, 必要时, 您可以 cd 进入相关的子目录。

6.6 Install

这里所设定的, 同样也不是 macro, 基本上, 您只须要在此设定一些 install 所需之指令。 如果您打算在程式套件里, 提供完整的 make install 指令设定, 那麽请在本段落设定中完成, 不然, 您也可以更改 makefile 档案里, 有关 make install 的部份, 然後仅在本段落设定中指定 make install。 或是, 也可以把整个 install 的指令交给 sh 来做。 记住, 您的目前所在目录位置, 应该已被重新设定为 source directory 的最上层。

6.7 Optional pre and post Install/Uninstall Scripts

程式套件在安装与解除安装之前後,您可以指定 script, 使其视情况加以执行。 进行此项动作的主要原因之一, 便是遇到如下的场合, 譬如说, 我们在安装或解除安装一些含有 shared library 的程式套件时, 需要执行 ldconfig。 各式 script 所需之 macro 名称如下:

这些段落设定的内容, 可以是任何 sh 型式之 script, 不过, 您无须指定关键叙述 #!/bin/sh

6.8 Files

本段落设定当中, 您必须列出程式套件内之所属档案名称。 RPM 本身并无从得知, 执行 make install 之後, 到底有哪些 binary 档案被安装进去, 目前并无他法可以直接解决此问题。 有些人建议在 install 程式套件的前後, 使用 find 指令来处理, 不过在一个多使用者的系统下, 这应该是不可行的, 因为在程式套件 build 的过程中, 可能有其他与程式套件本身无关的档案被产生。

另外还有一些 macro, 它们可用来做一些特殊的工作, 兹将其列述於下:

在档案列表里, 有个最大的注意事项, 便是目录的设定。 如果您不小心将 /usr/bin 列入, 那麽您的程式套件, 将会包括系统里 /usr/bin 底下的所有档案。

6.9 Building It

The Source Directory Tree

第一件事, 您必须选定一个适当的 build tree, 此项设定可在 /etc/rpmrc 档案里完成, 而大多数人会直接使用 /usr/src

您可能还需要建立下列的目录, 使得 build tree 的设定能够完成:

Test Building

首先, 您大概会想要取回 source 档案, 在没有使用 RPM 的情况下, 进行一次「纯净的」 build 动作。 其步骤便是, 解开 source 档案, 将该目录名称改为 $NAME.org, 然後再次解开 source 档案, 我们需要使用此一 source 来进行 build 动作。 进入此一 source 目录, 按照指示来进行 build, 如果您必须编辑任何东西, 您会需要一份 patch, 一旦您完成 build 工作, 便可清除 source 目录里的内容。 请确定将 configure script 里, 所有产生之档案加以清除, 然後再 cd 回到 source 目录之上层, 接著便可执行这样的动作:

diff -uNr dirname.orig dirname > ../SOURCES/dirname-linux.patch
上述指令会产生一份 patch, 您在 spec 档案可以使用到它。 注意到上面的 ''linux'' 名称, 它只是一个提示作用, 或许您可以使用其他名称, 诸如 ''config'' 或 ''bugs'' 之类的提示名称, 用以说明您何以制作此一 patch 档案。 同时, 您最好也在使用 patch 档案之前, 先观察里头的内容, 确定是否无意间包含了其他的 binary 档案。

Generating the File List

现在, 您已经有了一份可以拿来 build 的 source 档案, 而且您也知道如何完成其相关的动作, 如 build 与 install 等。 观察 install 时, 依序产生的结果, 我们将由此结果, 在 spec 档案中建立一份档案列表。 通常我们会在进行上述步骤的同时, 一起建立 spec 档案, 您可以先完成档案的起始部分, 和几个简单的部分, 然後再把其他部分的步骤加以完成。

Building the Package with RPM

一旦您有了一份 spec 档案, 一切便已就绪, 您可以准备 build 的测试动作。 最好的方式, 就是使用类似下列的指令:

rpm -ba foobar-1.0.spec

配合 -b 选项, 我们还可以使用其他有用的选项:

配合 -b 选项, 另外还有一些细项选项可供使用, 它们分别是:

6.10 Testing It

一旦有了 source 与 binary 的 rpm 档案, 您必须进行测试工作。 最简单且最好的方式, 就是使用另一台机器来测试, 也就是进行 build 动作之外的机器。 毕竟, 您刚在您的机器上, 完成一大堆的 make install 动作, 若在原机器上做测试, 当然会显得相当顺利罗。

您可以执行 rpm -u packagename 来进行测试, 但这样做还是有造假的可能, 因为在 build 的过程中, 您做了 make install 的动作, 如果您在档案列表中遗漏了某些东西, 那麽它不会被解除安装, 然後您再 reinstall 这份 binary 程式套件, 便会发现整个系统还是完整而运作正常的, 但实际上的 rpm 档案还是有问题。 因此请特别记住, 由於您执行的是 rpm -ba package, 而大多数的人, 会只以 rpm -i package 方式, 来安装您的程式套件。 当 binary 档案独自被安装时, 您必须确定在 buildinstall 的段落设定中, 并没有相关的部份对其有影响。

6.11 What to do with your new RPMs

一旦您作出了一份自己的 RPM 档案 ( 假定这份档案, 之前并未以 RPM 方式制作过 ), 您可以将您的作品贡献给别人 ( 此时假定您制作的 RPM 档案, 是可以自由传布的 )。 您可以考虑把它上传至 ftp.redhat.com

6.12 What Now?

请回顾上述的章节, 在「Testing」和「What to do with new RPMs」里, 我们希望所有的 RPM 档案都能被提供出来, 而且我们希望它们都会是好的 RPM 档案。 因此, 请多花一点时间好好地测试它们, 然後再花点时间将它们上传, 以造福普罗大众。 同时, 确定您只上传可供自由传布的软体。 商业软体与共享软体是应该被上传的, 除非它们有份许可声明在上面。 这样的软体, 包括有 Netscape software、 ssh、 pgp 等。


Next Previous Contents