rpm-howto.txt

linux-bible.rar linux-bible.rar

   里， 有关 make install 的部份， 然後仅在本段落设定中指定 make install。
   或是， 也可以把整个 install 的指令交给 sh 来做。 记住， 您的目前所在目
   录位置， 应该已被重新设定为 source directory 的最上层。
   
6.7 Optional pre and post Install/Uninstall Scripts

   程式套件在安装与解除安装之前後，您可以指定 script， 使其视情况加以执行
   。 进行此项动作的主要原因之一， 便是遇到如下的场合， 譬如说， 我们在安
   装或解除安装一些含有 shared library 的程式套件时， 需要执行 ldconfig。
   各式 script 所需之 macro 名称如下：
     * %pre 执行 pre-install scripts 的 macro。
     * %post 执行 post-install scripts 的 macro。
     * %preun 执行 pre-uninstall scripts 的 macro。
     * %postun 执行 post-uninstall scripts 的 macro。
       
   这些段落设定的内容， 可以是任何 sh 型式之 script， 不过， 您无须指定关
   键叙述 #!/bin/sh。
   
6.8 Files

   本段落设定当中， 您必须列出程式套件内之所属档案名称。 RPM 本身并无从得
   知， 执行 make install 之後， 到底有哪些 binary 档案被安装进去， 目前并
   无他法可以直接解决此问题。 有些人建议在 install 程式套件的前後， 使用
   find 指令来处理， 不过在一个多使用者的系统下， 这应该是不可行的， 因为
   在程式套件 build 的过程中， 可能有其他与程式套件本身无关的档案被产生。
   
   另外还有一些 macro， 它们可用来做一些特殊的工作， 兹将其列述於下：
     * %doc 用以标示在 install 程式套件时， 您所想要安装之 source 档案里的
       说明文件是哪些， 而这些说明文件会被安装在
       /usr/doc/$NAME-$VERSION-$RELEASE。 您可以在命令列上， 以此 macro 同
       时指定好几个说明文件名称， 或是以此 macro， 各别为它们一一完成指定
       。
     * %config 用以标示程式套件里的设定档案是哪些， 这包括像 sendmail.cf、
       passwd 之类的档案。 如果您事後 uninstall 了某个程式套件， 而且它含
       有设定档案， 那麽所有没有改变的档案会被移除， 而所有已经改变的档案
       ， 会在原档案名称之後， 加上 .rpmsave 的延伸名称。 同样的， 您可以
       在此同时列出多个档案名称。
     * %dir 在档案列表中， 标明某一个特定的目录， 用以说明该目录为某程式套
       件所拥有。 如果您在档案列表中指定一个目录名称， 但却没有在前面加
       上%dir macro， 那麽该目录内， 所有档案目录都会被包含在档案列表当中
       ， 并在稍後， 被当作是程式套件的一部份而全被安装进去。
     * %files -f <filename> 允许您引用 source 之 build 目录里， 某份档案清
       单的内容。 当您遇到某一个程式套件， 它可以建立自己的档案清单时， 这
       个选项便显得相当不错， 您只须要引用该份档案清单， 不必再自行辛苦地
       列出。
       
   在档案列表里， 有个最大的注意事项， 便是目录的设定。 如果您不小心将
   /usr/bin 列入， 那麽您的程式套件， 将会包括系统里 /usr/bin 底下的所有档
   案。
   
6.9 Building It

  The Source Directory Tree
  
   第一件事， 您必须选定一个适当的 build tree， 此项设定可在 /etc/rpmrc 档
   案里完成， 而大多数人会直接使用 /usr/src。
   
   您可能还需要建立下列的目录， 使得 build tree 的设定能够完成：
     * BUILD 此目录便是 RPM 进行所有 build 动作的工作目录。 您不必特别地在
       哪个目录进行测试性的 build 动作。
     * SOURCES 此目录存放著您的「起始」 (original) 原始 tar 档案、 与相关
       的 patch 档案， RPM 预设会寻找本目录。
     * SPECS 此目录存放所有之 spec 档案。
     * RPMS 此目录存放所有 build 产生之 binary 格式 RPM 档案。
     * SRPMS 此目录存放所有 source 格式 RPM 档案。
       
  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 选项， 我们还可以使用其他有用的选项：
     * p 指的是只执行 spec 档案之 prep 部份。
     * l 针对 %files 进行档案列表的比对检查动作。
     * c 执行 prep 与 compile 的动作。 当您不确定 source 档案是否能够
       build 时， 此选项显得相当有用。 或许您会觉得它并没有多大用处， 因为
       您可能想要继续修改 source 档案本身， 直到 build 後再开始使用 RPM，
       但一旦您熟悉 RPM 的用法後， 会发现它的便利之处。
     * i 执行 prep、 compile、 与 install。
     * b 执行 prep、 compile、 install、 并只 build 出一份 binary 程式套件
       。
     * a 执行所有的 build 动作 ( 包括 source 与 binary 的程式套件 )。
       
   配合 -b 选项， 另外还有一些细项选项可供使用， 它们分别是：
     * --short-circuit 会直接跳至某个特定的阶段 ( 仅可配合 c 与 i 选项来使
       用 )。
     * --clean 当执行完毕时， 移除相关的 build tree。
     * --keep-temps 会把所有的 temp 与 scripts 档案， 都保留在 /tmp 目录，
       您可以使用 -v 选项， 实际观察有哪些档案被产生。
     * --test 并不实际执行任何阶段的动作， 但有执行 keep-temp 的部份。
       
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 档案独
   自被安装时， 您必须确定在 build 或 install 的段落设定中， 并没有相关的
   部份对其有影响。
   
6.11 What to do with your new RPMs

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

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

   RPM 目前可用於 build 各式作业平台之程式套件， 如 Intel i386、 安装
   Linux 之 Digital Alpha、 与 Sparc 机器， 而且有人测试报告， 说明它也可
   以在 SGI 与 HP 工作站上使用。 RPM 有许多特色， 使得它能够轻松地支援在各
   式作业平台上 build 程式套件， 第一个特色便是在 /etc/rpmrc 档案里的
   ``optflags'' 设定项目， 当我们在 build 软体套件时， 它可用於指定平台架
   构的相关设定值。 另一个特色是 spec 档案里的 ``arch'' macro 项目， 根据
   所要进行 build 的平台架构， 您可以指定它们执行不同的工作。 另一个特色是
   在档案 header 处的 ``Exclude'' 设定项目。
   
7.1 Sample spec File

   下列以 ``fileutils'' 程式套件为例， 其 spec 档案的部份内容， 可用来在
   Alpha 与 Intel 平台架构上， 进行 build 的工作。
   
Summary: GNU File Utilities
Name: fileutils
Version: 3.16
Release: 1
Copyright: GPL
Group: Utilities/File
Source0: prep.ai.mit.edu:/pub/gnu/fileutils-3.16.tar.gz
Source1: DIR_COLORS
Patch: fileutils-3.16-mktime.patch

%description
These are the GNU file management utilities.  It includes programs
to copy, move, list, etc, files.

The ls program in this package now incorporates color ls!

%prep
%setup

%ifarch alpha
%patch -p1
autoconf
%endif
%build
configure --prefix=/usr --exec-prefix=/
make CFLAGS="$RPM_OPT_FLAGS" LDFLAGS=-s

%install
rm -f /usr/info/fileutils*
make install
gzip -9nf /usr/info/fileutils*

.
.
.

7.2 Optflags

   在此一□例中， 您可以发现 ``optflags'' 设定项目， 是如何由 /etc/rpmrc
   档案中发挥作用。 首先决定您所进行 build 动作的机器， 是哪一种平台架构，
   请将其正确之设定值， 指定到 RPM_OPT_FLAGS。 您必须针对程式套件之
   Makefile 档案， 进行 patch 的动作， 将一些通用的变数设定值， 加以改变以
   适用於您的环境 ( 如 -m486 与 -O2 )。 您可以 install 这份 source 套件，
   接著解开 source 并检查其 Makefile 档案， 以进一步找出更好的设定方式，
   然後观察 Makefile 的 patch 内容， 以了解我们必须做哪些改变。
   
7.3 Macros

   %ifarch 此一 macro 设定项目是非常重要的， 在许多场合， 您须要只针对某一
   特定平台架构， 进行一两个 patch 工作， 这种情况下， RPM 能够让您仅针对
   某一平台架构， 采用必要的 patch。
   
   在上述□例中， fileutils 有个提供给 64 bit 机器使用的 patch， 很明显地
   ， 这项 patch 仅需要由 Alpha 机器所采用， 因此， 我们针对 64 bit 的
   patch 部份， 增加一个 %ifarch 的 macro 设定项目， 其□例如下：
   
%ifarch axp
%patch1 -p1
%endif

   这样能保证， 除了 Alpha 机器之外， 其他平台架构的机器并不会采用此
   patch。
   
7.4 Excluding Architectures from Packages

   您可以在一个目录内， 同时管理各式作业平台的 RPM 原始档案， 这项功能使得
   我们在制作程式套件的时候， 不必限定於某些作业平台上。 因此您可以这样下
   指令：
   
rpm --rebuild /usr/src/SRPMS/*.rpm

   使得正确的程式套件能够被 build。 如果您尚未移植某个应用程式至某一特定的
   作业平台， 可以加上这样的一行内容：
   
ExcludeArch: axp

   到 source 程式套件当中， spec 档案的 header 处， 然後在原本进行 build
   的作业平台上， 再做一次 rebuild 动作。 此时， 您就有了一份在 Intel 机器
   上 build 完成的 source 程式套件， 同时它也很容易便能移□至 Alpha 机器上
   。
   
7.5 Finishing Up

   使用 RPM 来制作「多作业平台」的程式套件， 通常会比各别在该平台制作来得
   容易， 而且随著您制作越多的程式套件， 其效应会更加明显， 因为， 我们可
   以参考其他类似的原始程式套件内容， 得以处理制作时遇到的问题。
   
8. Copyright Notice

   本说明文件及其内容， 均受版权所保护， 在原文保持完整、 未被更动的情况下
   ， 允许将其转载， 也就是说， 您仅能对原文加以重新排版、 重新列印、 或进
   行转录。

References

   1. http://www.redhat.com/
   2. ftp://ftp.redhat.com/pub/redhat/code/rpm
   3. ftp://ftp.redhat.com/