  RPM HOWTO
  Donnie Barnes,djb@redhat.com
  V2.0, April 8, 1997
  神田 充 kanda@cmm.is.tohoku.ac.jp
  1997年9月7日

  訳者より：私自身、RPM の事を詳しく知りたいために この HOWTO を訳したの
  で、 RPM について初心者です。そのことを考慮してお読みください。また、
  実際の RPM パッケージを作成するにあたり、古高 和禎
  <furutaka@Flux.tokai.jaeri.go.jp>さんと石岡
  尚<ishioka@ppp01.infoPepper.or.jp>さんによって書かれた RPM-BUILD-HOWTO
  をお読みになる事をお勧めします。山縣 敦 <yamagata@jwu.ac.jp>さんが翻訳
  された前のバージョンも参考にさせて頂きました。翻訳の間違い等は指摘して
  頂けると幸いです。
  ______________________________________________________________________

  目次

  1. はじめに
  2. 概観
  3. 一般的な情報
     3.1 RPM の入手
     3.2 RPM のために必要なもの

  4. RPM の使用
  5. 現在 RPM で実際にできること
  6. RPM パッケージの作成
     6.1 rpmrc ファイル
     6.2 spec ファイル
     6.3 ヘッダ
     6.4 Prep
     6.5 Build
     6.6 Install
     6.7 pre ,post インストール / アンインストール スクリプト (任意)
     6.8 Files
     6.9 作成
        6.9.1 ソースディレクトリ ツリー
        6.9.2 作成テスト
        6.9.3 ファイルリストの生成
        6.9.4 RPM を用いたパッケージの作成
     6.10 テスト
     6.11 新しく作成した RPM パッケージをどうすれば良いか。
     6.12 What Now?

  7. マルチ アーキテクチャ用 RPM パッケージの作成
     7.1 サンプル spec ファイル
     7.2 optflags
     7.3 マクロ
     7.4 パッケージから アーキテクチャを除外する
     7.5 最後に

  8. 著作権告知

  ______________________________________________________________________

  1.  はじめに

  RPM とは、Red Hat Package Manager のことです。名前に Red Hat という文
  字が含まれていますが、誰もが使えるオープンパッケージングシステムです、
  新しいソフトウェアのソースコードから、簡単に再構築できるソースコード形
  式や、簡単にインストールとトラッキングを行なえるバイナリ形式でパッケー
  ジ化することができます。RPM は、全パッケージと、それらに含まれる全ファ
  イルのデータベースも維持します。このデータベースはパッケージについての
  照合とファイル と(もしくは)パッケージについての情報に対する問い合わせ
  に使われます。 Red Hat Software は、他のべンダーが RPM を調べて自分た
  ちの配布パッケージに使うことを奨励しています。RPM は非常に大規模なシス
  テムのための基礎を提供つつ、とても柔軟で使いやすいものになっており、完
  全にオープンに利用可能です。 GPL に基づき、使用料無しの使用及び配布が
  許可されています。バグリポートとバグフィックスは感謝されることでしょ
  う。

  RPM に関するより完全な文書として、Ed Bailey 著「Maximum RPM」が入手可
  能です。この本は www.redhat.com  <http://www.redhat.com> からダウン
  ロードもしくは購入できます。

  2.  概観

  はじめに、RPM の背景にある哲学のいくつかについて述べさせてもらいます。
  一つの設計目標は ``元の'' ソースの使用の余地を残すことでした。RPP (RPM
  がない以前に私たちがパッケージするのに利用していたしていたシステム) で
  は、私たちのソースパッケージは ``ハックされた'' ソースをもとに作成され
  ていました。理論的には、誰もがソース RPP をインストールでき問題無しに
  make できます。しかしソースはオリジナルなものではなくなってしまいまし
  たし、作成するために何が変更されたのか言及されていませんでした。元の
  ソースは別にあってダウンロードしなければならなりませんでした。RPM で
  は、私たちがコンパイルしたパッチと供に元のソースを手にすることになりま
  す。私たちはこれを大きなアドバンテージと見ます。なぜならいくつかの理由
  があります。一つは、もしプログラムの新しいバージョンが出たとき、RHLの
  元でコンパイルして得るためにスクラッチからはじめる必要はありません。作
  業することが必要かもしれないことを調べるためにパッチを見ることができま
  す。全てのコンパイルの時のデフォルトをこの方法で簡単に認識できます。

  RPM はまた強力な問い合わせのオプションを持つように設計されています。
  パッケージもしくは該当するファイルための全データベースを通して検索する
  ことができます。また、ファイルがどのパッケージに属していてそれがどこ作
  られたのかを簡単に見つけ出せます。RPM ファイルはそれ自身圧縮されたアー
  カイブです。しかし個々のパッケージを簡単にかつ素早く問い合わせることが
  できます。なぜなら、特別のバイナリヘッダがあなたがひょっとしたら知る必
  要のあること全てを非圧縮の形でパッケージに付け加えられているからです。
  これは高速な問い合わせを実現します。

  他の強力な特徴は、パッケージの照合能力です。もしあるパッケージのための
  重要なファイルを消してしまったか心配なら、それを照合してみてください。
  幾つかの異常を通告されるでしょう。この点で、必要ならばパッケージを再イ
  ンストールできます。所持していたどんな設定ファイルも同様に保存されま
  す。

  私たちは RPMに多くのアイディアとコンセプトを含めさせてもらった BOGUS
  ディストリビューションの方々に感謝します。RPM は完全に Red Hat
  Software によって書かれましたが、その動作は BOGUS (PM と PMS) によって
  書かれたコードを元にしています。

  3.  一般的な情報

  3.1.  RPM の入手

  RPM を入手するためにもっともよい方法は、Red Hat Linux をインストールす
  ることです。もしあなたがそれを望まないならば、それでもRPM を入手し使う
  ことができます。RPM は ftp.redhat.com
  <ftp://ftp.redhat.com/pub/redhat/code/rpm> から取得できます。

  3.2.  RPM のために必要なもの

  RPM を使うのに主に必要となるものは cpio 2.4.2 か それ以上のバージョン
  です。RPM という仕組みは Linux で使うために作られたものですが、他の
  Unix システムにも簡単に移植できるでしょう。実際、SunOS, Solaris, AIX,
  IRIX, AmigaOS などでもコンパイルできました。注意:異なったタイプの Unix
  システム上で生成されたバイナリパッケージは互換性を持っていないでしょ
  う。

  上記は RPM パッケージをインストールするのに最低限必要なものです。ソー
  スから RPM パッケージを作成するならば、一般的にパッケージを作成するの
  に必要なもの、たとえば gcc や make といったもの一式も必要になるでしょ
  う。

  4.  RPM の使用

  RPM を使ってパッケージをインストールするのは簡単です。

       rpm -i foobar-1.0-1.i386.rpm

  パッケージのアンインストールも簡単。

       rpm -e foobar

  ちょっと複雑になりますが、とても便利な使い方のひとつに、FTP を介して
  パッケージをインストールすることがあります。 もしネットワークに接続し
  ており、新しいパッケージをインストールしたいのならば、以下のように正し
  い URL でファイル名を明記すればよいのです。

       rpm -i ftp://ftp.pht.com/pub/linux/redhat/rh-2.0-beta/RPMS/foo-
       bar-1.0-1.i386.rpm

  注意: RPM は 現在 FTP 経由で、問い合わせ と(もしく)は インストールしか
  できません。これらは単純なコマンドですが、rpm は Usage メッセージから
  わかるように多数の方法で使われます。

  RPM version 2.3.9
  Copyright (C) 1997 - Red Hat Software
  This may be freely redistributed under the terms of the GNU Public License

  usage: rpm {--help}
         rpm {--version}
         rpm {--initdb}   [--dbpath <dir>]
         rpm {--install -i} [-v] [--hash -h] [--percent] [--force] [--test]
                          [--replacepkgs] [--replacefiles] [--root <dir>]
                          [--excludedocs] [--includedocs] [--noscripts]
                          [--rcfile <file>] [--ignorearch] [--dbpath <dir>]
                          [--prefix <dir>] [--ignoreos] [--nodeps]
                          [--ftpproxy <host>] [--ftpport <port>]
                          file1.rpm ... fileN.rpm
         rpm {--upgrade -U} [-v] [--hash -h] [--percent] [--force] [--test]
                          [--oldpackage] [--root <dir>] [--noscripts]
                          [--excludedocs] [--includedocs] [--rcfile <file>]
                          [--ignorearch]  [--dbpath <dir>] [--prefix <dir>]
                          [--ftpproxy <host>] [--ftpport <port>]
                          [--ignoreos] [--nodeps] file1.rpm ... fileN.rpm
         rpm {--query -q} [-afpg] [-i] [-l] [-s] [-d] [-c] [-v] [-R]
                          [--scripts] [--root <dir>] [--rcfile <file>]
                          [--whatprovides] [--whatrequires] [--requires]
                          [--ftpuseport] [--ftpproxy <host>] [--ftpport <port>]
                          [--provides] [--dump] [--dbpath <dir>] [targets]
         rpm {--verify -V -y} [-afpg] [--root <dir>] [--rcfile <file>]
                          [--dbpath <dir>] [--nodeps] [--nofiles] [--noscripts]
                          [--nomd5] [targets]
         rpm {--setperms} [-afpg] [target]
         rpm {--setugids} [-afpg] [target]
         rpm {--erase -e} [--root <dir>] [--noscripts] [--rcfile <file>]
                          [--dbpath <dir>] [--nodeps] [--allmatches]
                          package1 ... packageN
         rpm {-b|t}[plciba] [-v] [--short-circuit] [--clean] [--rcfile  <file>]
                          [--sign] [--test] [--timecheck <s>] specfile
         rpm {--rebuild} [--rcfile <file>] [-v] source1.rpm ... sourceN.rpm
         rpm {--recompile} [--rcfile <file>] [-v] source1.rpm ... sourceN.rpm
         rpm {--resign} [--rcfile <file>] package1 package2 ... packageN
         rpm {--addsign} [--rcfile <file>] package1 package2 ... packageN
         rpm {--checksig -K} [--nopgp] [--nomd5] [--rcfile <file>]
                             package1 ... packageN
         rpm {--rebuilddb} [--rcfile <file>] [--dbpath <dir>]
         rpm {--querytags}

  RPM の man ぺージを見れば、上記のオプションが何なのかわかります。 [訳
  注：翻訳された，rpm.8 が <http://www.linux.or.jp/jrpm/doc.html> から取
  得することができます。]

  5.  現在 RPM で実際にできること

  RPM はとても有益なツールで、ご存知の通りいくつかのオプションがありま
  す。それらの意味を理解するために一番の方法はいくつかの例を見る事です。
  これまでに 簡単なインストール(アンインストール)の説明をしましたので、
  ここではいくつかの例を示します。

  o  アクシデントによっていくつかのファイルを消去してしまいしかも何を消
     去したのか不確かであるとしましょう。もし全システムに照合し何を失っ
     たかを知りたいならば、以下のようにすれば大丈夫です。

       rpm -Va

  o  見覚えのないファイルを偶然発見したとしましょう。それはどのパッケー
     ジのものであるかを見つけるために、以下のようにすれば大丈夫です。

       rpm -qf /usr/X11R6/bin/xjewel

  その出力は以下のようになります。

       xjewel-1.6-1

  o  新しい koules RPM を見つけたが、それが何であるか知らない時には、以
     下のようにすれば何か情報が得られます。

       rpm -qpi koules-1.2-2.i386.rpm

  その出力は以下のようになります。

       Name        : koules                      Distribution: Red Hat Linux Colgate
       Version     : 1.2                               Vendor: Red Hat Software
       Release     : 2                             Build Date: Mon Sep 02 11:59:12 1996
       Install date: (none)                        Build Host: porky.redhat.com
       Group       : Games                         Source RPM: koules-1.2-2.src.rpm
       Size        : 614939
       Summary     : SVGAlib action game with multiplayer, network, and sound support
       Description :
       This arcade-style game is novel in conception and excellent in execution.
       No shooting, no blood, no guts, no gore.  The play is simple, but you
       still must develop skill to play.  This version uses SVGAlib to
       run on a graphics console.

  o  インストールする koules RPM にはどのようなファイルが含まれるか知り
     たい時には以下のようにしてください。

       rpm -qpl koules-1.2-2.i386.rpm

  その出力は以下のようになります。

       /usr/doc/koules
       /usr/doc/koules/ANNOUNCE
       /usr/doc/koules/BUGS
       /usr/doc/koules/COMPILE.OS2
       /usr/doc/koules/COPYING
       /usr/doc/koules/Card
       /usr/doc/koules/ChangeLog
       /usr/doc/koules/INSTALLATION
       /usr/doc/koules/Icon.xpm
       /usr/doc/koules/Icon2.xpm
       /usr/doc/koules/Koules.FAQ
       /usr/doc/koules/Koules.xpm
       /usr/doc/koules/README
       /usr/doc/koules/TODO
       /usr/games/koules
       /usr/games/koules.svga
       /usr/games/koules.tcl
       /usr/man/man6/koules.svga.6

  これらはほんの数例です。一度 RPM に親しめばより創造的な事を簡単に思い
  つく事ができます。

  6.  RPM パッケージの作成

  RPM パッケージの作成は全く簡単です、特に作成しようとしているソフトウェ
  アを手に入れられるならなおさらです。

  RPM を作成する基本的な課程は以下の通りです。

  o  あなたのシステムに適合するように /etc/rpmrc を確実に設定します。

  o  あなたのシステムで RPM を作成するためにソースコードを手に入れます。

  o  正しく作成するために必要なソースへの変更をパッチにします

  o  パッケージのための spec ファイルを作成します。

  o  全ての物が正しい場所におかれている事を確認します。

  o  RPM を用いてパッケージを作成します。

  一般的な操作の下で、RPM はバイナリとソースパッケージを作成します。

  6.1.  rpmrc ファイル

  現在、RPM の設定は /etc/rpmrc ファイルのみが有効です。例えば以下のよう
  になります。 [訳注、デフォルトとして、/usr/lib/rpmrc というものがあ
  り、個人の設定ファイルとして個人のホームディレクトリに .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 の行は /etc/rpmrc もしくは spec ファイルのヘッダから
  vendor の行を探そうとします。これを無効にするには、ナンバーを 0 に変え
  て下さい。require_distribution と require_group の行も同様です。

  次の行は distribution 行です。ここか spec ファイルのヘッダ中に定義でき
  ます。vender 行も同様ですが、何でもよいです。(例、Joe's Software and
  Rock Music Emporium)

  RPM はまた現在複数のアーキテクチャ上でパッケージを作成する事をサポート
  しています。rpmrc ファイルは作成時にアーキテクチャ固有のフラグが求めら
  れるようなパッケージを作成するのに必要な"optflag" 変数を持つ事ができま
  す。

  上記のマクロに付け加えて、さらにいくつかあります。

       rpm --showrc

  とすれば、どのようなタグが設定され、有効な全てのフラグは何かわかりま
  す。

  6.2.  spec ファイル

  sepc ファイルについて述べて行きます。spec ファイルはパッケージを作成す
  るために必要です。spec ファイルは作成の仕方の指示を含むソフトウェアの
  説明とインストールされる全てのバイナリファイルのリストです。

  標準的な規則に従って spec ファイルの名前を付けたほうがよいでしょう。そ
  れは、パッケージ名-ダッシュ-バージョン番号-ダッシュ-リリース番号- ドッ
  ト-spec とすべきです。

  ここに簡単な spec ファイルがあります。(vim-3.0-1.spec) [訳
  注、vim-3.0-1.spec とありますが、これはeject-1.4-3.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.  ヘッダ

  ヘッダは書き込む必要のあるいくつかの標準的なフィールドがあります。また
  いくつか注意があります。フィールドは以下のように書き込まなければなりま
  せん。

  o  Summary: これは一行のパッケージの説明です。

  o  Name: これは使おうとしている rpm ファイル名からの文字列でなければな
     りません。

  o  Version: これは使おうとしている rpm ファイル名からのバージョン番号
     でなければなりません。

  o  Release: これは同じバージョンのパッケージのためのリリース番号です。
     (例えば、パッケージを作成しそれがわずかに壊れているのを発見し再度作
     成する必要があるならば、次のパッケージのリリース番号は2となりま
     す。)

  o  Icon: これは他の高レベルなインストールツール(Red Hat の "glint"の様
     な)を用いる為のアイコン名です。それはgif ファイルで SOURCES ディレ
     クトリに置かなければなりません。

  o  Source: この行は元のソースファイルのホームロケーションを指します。
     再びソースファイルを手に入れたいとか新しいバージョンをチェックした
     い時に使われます。注意：この行のファイル名とあなたのシステム上に持
     つファイル名は一致していなければなりません。(例えば、ソースファイル
     をダウンロードしその名前は変えてはいけません。) 一つ以上のソース
     ファイルを明記したい時は以下のように書きます。

       Source0: blah-0.tar.gz
       Source1: blah-1.tar.gz
       Source2: fooblah.tar.gz

  これらのファイルは SOURCES ディレクトリに置きます。(ディレクトリ構造は
  後の節  "ソース ディレクトリ ツリー" で扱います。)

  o  ・Patch: これは再びパッチをダウンロードする必要がある時にそれを見つ
     ける事のできる場所です。注意：あなたが自分で作成したパッチを作る時
     ファイル名は使う名前と一致しなければなりません。例えば以下のようで
     す。

       Patch0: blah-0.patch
       Patch1: blah-1.patch
       Patch2: fooblah.patch

  これらのファイルは SOURCES ディレクトリに置きます。

  o  Copyright: この行はパッケージがどのような著作権であるか表示します。
     GPL、BSD、MIT、public domain、distributable、commercial の様なもの
     を使うべきです。

  o  BuildRoot: この行は新しいパッケージを作成、インストールするための "
     ルート" のディレクトリを明記します。あなたのマシーンにインストール
     する前にパッケージをテストするのを助けるために使う事ができます。 [
     訳注、ここに記述するだけでは、作成およびテストはできません。詳しく
     は、RPM-BUILD-HOWTO を読むと良いでしょう。]

  o  Group: この行は高レベルなインストールプログラム(Red Hat の "glint"
     のような)に階層構造の中でこのプログラムがどこに属するのかを明示する
     ためにつかわれます。現在の グループ ツリーは以下のようになっていま
     す。[訳注、日本向けに Extensions/Japanese というものあります。]

       Applications
           Communications
           Editors
               Emacs
           Engineering
           Spreadsheets
           Databases
           Graphics
           Networking
           Mail
           Math
           News
           Publishing
               TeX
       Base
           Kernel
       Utilities
           Archiving
           Console
           File
           System
           Terminal
           Text
       Daemons
       Documentation
       X11
           XFree86
               Servers
           Applications
               Graphics
               Networking
           Games
               Strategy
               Video
           Amusements
           Utilities
           Libraries
           Window Managers
       Libraries
       Networking
           Admin
           Daemons
           News
           Utilities
       Development
           Debuggers
           Libraries
               Libc
           Languages
               Fortran
               Tcl
           Building
           Version Control
           Tools
       Shells
       Games

  o  %description これは本当はヘッダの項目ではありません、しかしヘッダの
     中に記述されるべきです。パッケージと(もしくは)サブパッケージに一つ
     の説明(description)のタグが必要です。これはパッケージの包括的な説明
     を与えるために使われるべき複数行のフィールドです。

  6.4.  Prep

  これは、spec ファイル中の2番目のセクションです。作成用に準備するソース
  を得るために使われます。ここで、パッチの当てられたソースを得るために必
  要な事をし make するために必要な準備をします。

  注意：各セクションはシェルスクリプトを実際に実行するための場所です。簡
  単に sh スクリプトを作成し、ソースを解凍しパッチを当てるために %prep
  タグの後にそれを置く事ができます。しかしながら、この中には上記の事を支
  援するためのマクロがあります。

  それらの最初マクロのは、%setup マクロです。そのもっとも簡単な形は(コマ
  ンドラインのオプションなし)、単にソースを解凍し できたソースディレクト
  リの中に cd するだけです。以下のオプションがあります。

  o  -n name は列挙された name に作成ディレクトリの名前をセットします。
     デフォルトは $NAME-VERSION です。他の可能性として $NAME、
     ${NAME}${VERION}、メインの tar ファイルが用いているものです。 (これ
     らの "$" 変数は spec ファイル中の本当の変数でない事に注意して下さ
     い。これらは参考のためにここで使われたものです。実際には変数ではな
     くパッケージ中の本当の名前とバージョンを使う必要があります。)

  o  -c は tar ファイルを解凍する前に名付けられたディレクトリを作りそこ
     に cd します。

  o  -b # はディレクトリに cd する前に Source# を 解凍(untar)します。 (
     これは -c オプションと一緒に用いるのは意味がありません、しないで下
     さい。) これは複数のソースファイルがある時のみ役に立ちます。

  o  -a # は ディレクトリに cd した後に Source# を解凍(untar)します。

  o  -T このオプションはソース解凍(untar)のデフォルト動作を無効にしま
     す。解凍(untar)されたメインのソースファイルを得るために -b 0 もしく
     は -a 0 を必要とします。2つめのソースがある時にこれを必要とします。

  o  -D は解凍する前にディレクトリを消去しません。これは setup マクロが
     複数ある時のみ有用です。最初の setup マクロの後の setup マクロでの
     み使うべきです。(決して最初の setup マクロで使わないで下さい。)

     次に有益なマクロは %patch マクロです。このマクロはソースにパッチを
     当てる課程の自動化を助けます。いくつかのオプションがありそれは以下
     の通りです。

  o  # はパッチファイルとして Patch# を利用します。

  o  -p # patch(1) コマンドのための取り除くディレクトリの数を明記しま
     す。

  o  -P デフォルトの動作では Patch (もしくは Patch0)を当てます。このフラ
     グはデフォルトの動作を禁止するので解凍(untar)されたソースファイルを
     得るために 0 を必要とします。このオプションは最初のマクロと異なる大
     きい番号を求められる2番目(もしくはそれ以降)の %patch マクロで有用で
     す。

  o  本来の %patch # -p コマンドの代わりに %patch# も使えます。

     以上で必要なマクロは全部です。これらを正しく記述した後に、sh スクリ
     プトを用いて他のあらゆる必要なセットアップをする事もできま
     す。%build マクロ(これは次節で説明します。)が sh を経由して実行され
     るまで何でも含められます。ここで行いたい事の形は上記の例を見て下さ
     い。

  6.5.  Build

  このセクションにはマクロはありません。ソースを解凍(untar)し、パッチを
  当て、ディレクトリに cd したならここでは単にソフトウェアを作成するため
  に必要なコマンドを記述して下さい。これは単に sh に渡す他のコマンドの集
  まりなので、どんな合法的な sh のコマンド(コメントを含む)でもここで実行
  できます。[訳注：これはシェルの組み込みコマンドの事だけをいっているの
  ではありません。]これらのセクションの各々で作業ディレクトリはソース
  ディレクトリの一番上にリセットされますのでそれを覚えておいて下さい。も
  し必要ならばサブディレクトリに cd して下さい。

  6.6.  Install

  ここにもマクロはありません。基本的にここにインストールに必要なコマンド
  なら何でも置けます。作成したパッケージ中で make install が有効なら、こ
  こに置きます。そうでないのなら、make install の為の makefile へのパッ
  チを当て、make install をするか、sh コマンドによって手動でインストール
  する事もできます。現在の作業ディレクトリがソースディレクトリのトップレ
  ベルである事を考慮して下さい。

  6.7.  pre ,post インストール / アンインストール スクリプト (任意)

  バイナリパッケージのインストール / アンインストール を行う前と後に実行
  するスクリプトをここに置く事ができます。シェアードライブラリを含むパッ
  ケージを インストールもしくはアンインストールした後に ldconfig を実行
  するような事をするためにこのタグがあります。以下に各々のスクリプトのた
  めのマクロがあります。

  o  %pre はインストールする前のスクリプトためのマクロです。

  o  %post はインストールした後のスクリプトのためのマクロです。

  o  %preun はアンインストールする前のスクリプトのためのマクロです。

  o  %postun は アンインストールした後のスクリプトのためのマクロです。

  6.8.  Files

  このセクションはバイナリパッケージのためのファイルの一覧を表示しなけれ
  ばなりません。RPM は make install の結果どのバイナリがインストールされ
  たのか知る方法がないためです。これをする方法はありません! パッケージの
  インストール前と後に find を実行すればよいのではないかと疑問に思う人も
  いるかもしれません。マルチユーザーシステムにおいて、パッケージと関係の
  ないファイルがパッケージを作成している課程の間に作られているかもしれな
  いのでこれは受け入れられません。

  同様に特別な事をするために有効なマクロがいくつかあります。以下に説明し
  ます。

  o  %doc はバイナリをインストールする際にインストールしたいソースパッ
     ケージ中のドキュメントに印を付けるのに使われます。ドキュメントは
     /usr/doc/$NAME-$VERSION-$RELEASE にインストールされます。このマクロ
     を使ってコマンドライン上で複数のドキュメントの一覧を列挙するか、各
     ドキュメントごとにマクロを使って別々に列挙することができます。

  o  %config はパッケージ中の設定ファイルに印を付けるのに使われます。こ
     れは sendmail.cf、passwd などのようなものを含みます。もし後に設定
     ファイルを含むパッケージをアンインストールするならば、変更されてい
     ないファイルは削除され、変更されたファイルはもとファイル名に
     .rpmsave という拡張子を付加されたものに名前が変更されます。このマク
     ロでも同時に複数のファイルの一覧を列挙できます。

  o  %dir パッケージによって所有され含まれるファイル一覧中の単一のディレ
     クトリに印を付けます。デフォルトでは、%dir マクロを使わずにディレク
     トリ名を表示したなら、そのディレクトリ中の全てがファイル一覧に含ま
     れそして後にそのパッケージの一部としてインストールされます。

  o  %files -f <filename> はソースの作成ディレクトリ中の任意のファイルを
     リストに加える事ができます。これはパッケージ自身のファイルリストを
     作成する事ができるパッケージがある場合に便利です。その時ここにその
     ファイルリストを含めます、そして特にファイルを一覧表示してはなりま
     せん。

  ファイル一覧中の最大の注意点はディレクトリの一覧です。もし間違って
  /usr/bin を一覧に記してしまったら、バイナリパッケージはあなたのシステ
  ムの /usr/bin 中の全てのファイルを含んでしまいます。

  6.9.  作成

  6.9.1.  ソースディレクトリ ツリー

  まず最初に必要な事は、きちんと設定された作成ディレクトリツリーです。こ
  れは /etc/rpmrc ファイルを用いて設定可能です。多くの人々は /usr/src を
  使うでしょう。

  作成ソースディレクトリツリーを作るために以下のディレクトリを作る必要が
  あるかもしれません。

  o  BUILD は RPM により全ての作成が行われるディレクトリです。特に他の場
     所で作成のテストを行う必要はありませんが、ここは RPM が作成する用い
     るところです。

  o  SOURCES はオリジナルのソース(tar)ファイルとパッチを置くディレクトリ
     です。ここは、RPM がデフォルトで探すディレクトリです。

  o  SPECS は全ての spec ファイルを置くディレクトリです。

  o  RPMS は RPM が作成したバイナリ RPM パッケージを置くディレクトリです

  o  SRPMS は 全てのソース RPM パッケージを置くディレクトリです。

  6.9.2.  作成テスト

  おそらく最初にしたいことは、RPM を用いずに作成するためのソースツリーを
  得ることでしょう。これをするために、ソースを解凍し、ディレクトリ名を
  $NAME.orig に変更して下さい。そしてもう一度ソースを解凍して下さい。そ
  してこのソースを作成に使用して下さい。ソースディレクトリに入り作成する
  ための指示にしたがって下さい。もし何か編集をしなければならないなら、
  パッチが必要となります。一度それを作るためにソースディレクトリをきれい
  にします。./configure スクリプトにより生成されたファイルを確認し削除し
  ます。[訳注：要するに、いわゆる make 一発状態にすれば良いという事で
  す。] そして、ソースディレクトリの親ディレクトリに cd します。以下のよ
  うにします。

       diff -uNr dirname.orig dirname > ../SOURCES/dirname-linux.patch

  これは、spec ファイルで使用可能なパッチを作成します。上記の"linux"は単
  に識別子であることに注意して下さい。なぜパッチを作成しなければならない
  かを説明するために "config" や "bugs" の様なより説明的なものを使っても
  よいでしょう。間違ってバイナリを含めないように確認するために作成した
  パッチを使用する前に調べるのはよい考えです。

  6.9.3.  ファイルリストの生成

  作成するためのソースを手にいれ、それをどうやって作成するかわかったなら
  ば、作成しインストールします。インストールの結果の出力から spec ファイ
  ルで用いるためのファイルリストを作成します。私たちは、たいてい全てのス
  テップで並行して spec ファイルを作成しています。最初のファイルリストを
  作成して簡単な部分を書き込み、そして順を追って埋めていきます。

  6.9.4.  RPM を用いたパッケージの作成

  spec ファイルを書き終えたなら、パッケージを作成する準備ができました。
  もっとも有効な方法は、以下のようなコマンドを使うことです。

       rpm -ba foobar-1.0.spec

  -b スイッチには以下のような有用なオプションがあります。

  o  p は spec ファイルの prep セクションだけを実行します。

  o  l は %files のリストをチェックします。

  o  c は prep セクションを実行し コンパイルを行います。これはソースが完
     全に構築できるものかどうか不確実な時に役立ちます。ソースを構築しそ
     れから RPM を使いはじめるまでは、ソースのみで作業し続けたいでしょう
     から、役に立たないと思われます。しかし一旦 RPM を使うのに慣れてしま
     えば、それを使う例が見つかるでしょう。 [訳注、%Build セクションの有
     効性を確認するぐらいでしょう。]

  o  i は prep セクションを実行し、コンパイル インストールを行います。

  o  b は prep セクションを実行し、コンパイル インストールを行い、バイナ
     リパッケージのみを作成します。

  o  a は全てを作成します。(ソースとバイナリのパッケージの両方)

  -b スィッチには以下のようないくつかの変更子があります。

  o  --short-circuit は指定された処理を飛ばします。(c と i でのみ使用で
     きます。)

  o  --clean はパッケージの作成が終った後に作成したディレクトリツリーを
     消去します。

  o  --keep-temps は /tmp 以下に作られた全ての一時ファイルとスクリプトを
     保存します。実は -v オプションを用いることにより /tmp に作られた
     ファイルを見ることができます。

  o  --test は実際にはどの処理も実行はしませんが、keep-temp は行います。

  6.10.  テスト

  いったん、ソース及びバイナリの rpm パッケージを作成したら、それをテス
  トする必要があります。最も簡単で良い方法は、パッケージを作成したマシン
  と全く異なったマシン上でテストする事です。なぜなら、あなたのマシン上で
  何度も make install をしているので、きちんとインストールされるはずだか
  らです。

  テストのために rpm -u パッケージ名 とすることもできます、[訳注：おそら
  くこれは typo で rpm -e でしょう。rpm -u は現在では動作しません。 ]し
  かしパッケージ作成の時に make install を実行しているので間違う事もあり
  ます。もしファイルリストに洩れがあると、アンインストールされません。そ
  の時にはバイナリパッケージを再インストールしてシステムを再び完全なもの
  にします、しかし rpm パッケージはまだ完全ではありません。あなたは、
  rpm -ba specファイル名 をしただけだという事をしっかり心に止めておいて
  ください。多くの人々は パッケージをインストールするのに rpm -i パッ
  ケージ名 を行うだけです。バイナリがインストールされる時に必要な事を
  build セクションや install セクションで何もしていないことを確認してく
  ださい。

  6.11.  新しく作成した RPM パッケージをどうすれば良いか。

  いったん、あなたが RPM パッケージを作成したなら(すでに何か RPM 化した
  と仮定します)、あなたの作成したパッケージで他の人に貢献する事ができま
  す(作成した RPM パッケージが自由に配布可能なものとします)。そうするた
  めに、ftp.redhat.com にアップロードしてください。
  <ftp://ftp.redhat.com>

  6.12.  What Now?

  新しい RPM パッケージですることとテストに関しては上記のセクションを見
  てください。私達は 取得可能な 全ての RPM パッケージを募集しています。
  そして、それらが素晴らしい RPM パッケージであることを望んでいます。作
  成したパッケージをよく時間をかけてテストしてください。そして、万人の利
  益のためにそれをアップロードするために時間をかけてください。同様に、自
  由に配布できるソフトウェアのみをアップロードするようにしてください。商
  用ソフトウェア及びシェアウェアはそれらの著作権がはっきりと自由に配布す
  る事が許される事を言及してない限りアップロードすべきではありません。こ
  れには、Netscape ソフトウェア、ssh、pgp 等が含まれます。

  7.  マルチ アーキテクチャ用 RPM パッケージの作成

  RPM は現在 Intel i386、Degital Alpha、Sparc 用にパッケージを作成するた
  めに使う事ができます。SGI と HP のワークステーション上でも同様に動く事
  が報告されています。全てのプラットフォーム上で簡単にパッケージを作成す
  るための特徴がいくつかあります。まず第一に /etc/rpmrc の中の "optflag"
  の指示です。それはソフトウェアを作成する時に使われるフラグをアーキテク
  チャ特有の値に設定するために使う事ができます。他の機能として spec ファ
  イル中の "arch" マクロがあります。それは作成するアーキテクチャに依存す
  る異なる作業をするために使う事ができます。他に、ヘッダ中の "Exclude"
  の指示です。

  7.1.  サンプル spec ファイル

  以下は "fileutils" パッケージの spec ファイルの一部です。 Alpha と
  Intel 向けの両方を作成するための構成です。

  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

  この例では、どのように /etc/rpmrc 中の "optflags" の指示が使われている
  か分かるでしょう。あなたが作成しているアーキテクチャに依存する適当な値
  が RPM_OPT_FLAGS に与えられています。使用している(-m486 や -O2 のよう
  な) 通常の指示の代わりにこの変数を用いるには、パッケージの Makefile に
  パッチを当てなければなりません。このソースパッケージをインストールする
  ことによって必要となることをソースを解凍して Makefile を調べることが
  良いと感じるでしょう。その時、Makefile のためのパッチをしらべ、何を変
  えねばならないかを見てください。

  7.3.  マクロ

  %ifarch マクロはとても重要です。多くの場合一つのパッチもしくは特定の
  アーキテクチャ用の二つのパッチを作る必要があるでしょう。このような場
  合、RPM は適したアーキテクチャ用のパッチのみを当てることができます。

  上記の例として、fileutils は64ビットマシン向けのパッチを持っています。
  明らかに、これは Alpha 上にのみ当てられるべきです。それで、私達は、64
  ビットパッチのところに %ifarch マクロを付け加えました。

       %ifarch axp
       %patch1 -p1
       %endif

  これは Alpha 以外のアーキテクチャには当てられないパッチであることを保
  証します。

  7.4.  パッケージから アーキテクチャを除外する

  全てのプラットホームのために一つのディレクトリでソース RPM パッケージ
  をメンテナンスできるようにするために、私達はあるアーキテクチャ上で作成
  されることからパッケージを"除外"するための機能を実装しました。これは以
  下のように実行できます。

       rpm --rebuild /usr/src/SRPMS/*.rpm

  そして正しくパッケージが作成されます。もしあるプラットホーム向けにアプ
  リケーションを移植していないのならば、あなたがしなければならないこと全
  てはソースパッケージの spec ファイルのヘッダに以下のような一行を付け加
  えることです。

       ExcludeArch: axp

  そのようにしてから、作成するプラットホーム上でパッケージを再作成してく
  ださい。そうすれば、あなたは Intel 上で作成するためのソースパッケージ
  を手にすることになり、Alpha の部分は簡単に飛ばすことができます。

  7.5.  最後に

  マルチ アーキテクチャ用のパッケージを作成するために RPM を用いることは
  たいていパッケージを両方のアーキテクチャ上で作成するよりも簡単です。し
  かしながら、作成するのがとても難しいパッケージを作成すればより簡単に
  なっていきます。いつものように、RPM パッケージを作成するのにつまった時
  に最もよい助けとなることは似たようなソースパッケージを調べることです。

  8.  著作権告知

  この文書と内容は著作権によって保護されています。この文書の再配布は内容
  が完全もとのままで無変更である場合に限り許されます。言い換えれば、文書
  の形式の変更及び転載もしくは再配布のみさしつかえありません。

  [訳者より：この部分は原文も掲載しておきます。]

  This document and its contents are copyright protected.
  Redistribution of this document is permitted as long as the content
  remains completely intact and unchanged.  In other words, you may
  reformat and reprint or redistribute only.

