<!doctype linuxdoctr system>
<article>
<title>RPM HOWTO
<author>Donnie Barnes,<tt/djb@redhat.com/
<date>V2.0, April 8, 1997
<trans>神田 充 <tt/kanda@cmm.is.tohoku.ac.jp/
<tdate>1997年9月7日
<abstract>
訳者より：私自身、RPM の事を詳しく知りたいために この HOWTO を訳したので、
RPM について初心者です。そのことを考慮してお読みください。また、実際の
RPM パッケージを作成するにあたり、古高 和禎
&lt;furutaka@Flux.tokai.jaeri.go.jp&gt;さんと
石岡 尚&lt;ishioka@ppp01.infoPepper.or.jp&gt;さんによって書かれた 
RPM-BUILD-HOWTO をお読みになる事をお勧めします。山縣 敦
&lt;yamagata@jwu.ac.jp&gt;さんが翻訳された前のバージョンも参考にさせて
頂きました。翻訳の間違い等は指摘して頂けると幸いです。
</abstract>
<toc>
<!-- 
<sect>Introduction
<p>
RPM is the <bf/R/ed Hat <bf/P/ackage <bf/M/anager.  While it does contain
Red Hat in the name, it is completely intended to be an open packaging
system available for anyone to use.  It allows users to take source
code for new software and package it into source and binary form such
that binaries can be easily installed and tracked and source can be 
rebuilt easily.  It also maintains a database of all packages 
and their files that can be used for verifying packages and querying 
for information about files and/or packages.
<p>
Red Hat Software encourages other distribution vendors to take the
time to look at RPM and use it for their own distributions.  RPM is
quite flexible and easy to use, though it provides the base for
a very extensive system.  It is also completely open and available,
though we would appreciate bug reports and fixes.   Permission is
granted to use and distribute RPM royalty free under the GPL.  
<p>
More complete documentation is available on RPM in the book by
Ed Bailey, <em/Maximum RPM/.  That book is available for download
or purchase at <url url="http://www.redhat.com" name="www.redhat.com">.
-->
<sect>はじめに
<p>
RPM とは、<bf/R/ed Hat <bf/P/ackage <bf/Ma/nager のことです。名前に 
Red Hat という文字が含まれていますが、誰もが使えるオープンパッケージングシステム
です、新しいソフトウェアのソースコードから、簡単に再構築できる
ソースコード形式や、簡単にインストールとトラッキングを行なえるバイナリ形式で
パッケージ化することができます。RPM は、全パッケージと、
それらに含まれる全ファイルのデータベースも維持します。
このデータベースはパッケージについての照合とファ
イル と(もしくは)パッケージについての情報に対する問い合わせに使われます。
Red Hat Software は、他のべンダーが RPM を調べて自分たちの配布パッケージに
使うことを奨励しています。RPM は非常に大規模なシステムのための基礎を提
供つつ、とても柔軟で使いやすいものになっており、完全にオープンに利用可能です。
GPL に基づき、使用料無しの使用及び配布が許可されています。バグリポートと
バグフィックスは感謝されることでしょう。

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

<p>
First, let me state some of the philosophy behind RPM.  One design
goal was to allow the use of ``pristine'' sources.  With RPP (our
former packaging system of which <em/none/ of RPM is derived), our
source packages were the ``hacked'' sources that we built from.
Theoretically, one could install a source RPP and then <tt/make/ it
with no problems.  But the sources were not the original ones, and
there was no reference as to what changes we had to make to get it
to build.  One had to download the pristine sources separately.
With RPM, you have the pristine sources along with a patch that
we used to compile from.  We see this as a big advantage.  Why? 
Several reasons.  For one, if a new version of a program comes out,
you don't necessarily have to start from scratch to get it to 
compile under RHL.  You can look at the patch to see what you
<em/might/ need to do.  All the compile-in defaults are easily
visible this way.
<p>
RPM is also designed to have powerful querying options.  You
can do searches through your entire database for packages or 
just certain files.  You can also easily find out what package a
file belongs to and where it came from.  The RPM files themselves
are compressed archives, but you can query individual packages
easily and <em/quickly/ because of a custom binary header added
to the package with everything you could possibly need to know 
contained in uncompressed form.  This allows for <em/fast/ querying.
<p>
Another powerful feature is the ability to verify packages.  If you
are worried that you deleted an important file for some package,
just verify it.  You will be notified of any anomalies.  At that point,
you can reinstall the package if necessary.  Any config files that
you had are preserved as well.
<p>
We would like to thank the folks from the BOGUS distribution for
many of their ideas and concepts that are included in RPM.  While
RPM was completely written by Red Hat Software, its operation is based
on code written by BOGUS (PM and PMS).  
-->
<sect>概観
<p>
はじめに、RPM の背景にある哲学のいくつかについて述べさせてもらいます。
一つの設計目標は ``元の'' ソースの使用の余地を残すことでした。RPP (RPM が
ない以前に私たちがパッケージするのに利用していたしていたシステム) では、
私たちのソースパッケージは ``ハックされた'' ソースをもとに作成されていまし
た。理論的には、誰もがソース RPP をインストールでき問題無しに make でき
ます。しかしソースはオリジナルなものではなくなってしまいましたし、作成
するために何が変更されたのか言及されていませんでした。元のソースは別
にあってダウンロードしなければならなりませんでした。RPM では、私たち
がコンパイルしたパッチと供に元のソースを手にすることになります。私た
ちはこれを大きなアドバンテージと見ます。なぜならいくつかの理由があり
ます。一つは、もしプログラムの新しいバージョンが出たとき、RHLの元で
コンパイルして得るためにスクラッチからはじめる必要はありません。作業す
ることが必要かもしれないことを調べるためにパッチを見ることができます。
全てのコンパイルの時のデフォルトをこの方法で簡単に認識できます。

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

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

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

<!-- 
<sect>General Information
<p>
<sect1>Acquiring RPM
<p>
The best way to get RPM is to install Red Hat Linux.  If
you don't want to do that, you can still get and use RPM.  It can
be acquired from <url url="ftp://ftp.redhat.com/pub/redhat/code/rpm" 
name="ftp.redhat.com">.
-->
<sect>一般的な情報
<p>
<sect1>RPM の入手
<p>
RPM を入手するためにもっともよい方法は、Red Hat Linux をインストールす
ることです。もしあなたがそれを望まないならば、それでもRPM を入手し使う
ことができます。RPM は ftp.redhat.com
<url url=
"ftp://ftp.redhat.com/pub/redhat/code/rpm">
から取得できます。

<!-- 
<sect1>RPM Requirements
<p>
The main requirement to run RPM is cpio 2.4.2 or greater.  While 
this system is intended for use with
Linux, it may very well be portable to other Unix systems.  It has,
in fact, been compiled on SunOS, Solaris, AIX, Irix, AmigaOS, and 
others.  Be warned, the binary packages generated on a
different type of Unix system will not be compatible.
<p>
Those are the minimal requirements to install RPMs.  To build RPMs from
source, you also need everything normally required to build a package,
like <tt/gcc/, <tt/make/, etc.
-->
<sect1>RPM のために必要なもの
<p>
RPM を使うのに主に必要となるものは cpio 2.4.2 か それ以上のバージョン
です。RPM という仕組みは Linux で使うために作られたものですが、他の 
Unix システムにも簡単に移植できるでしょう。実際、SunOS, Solaris, AIX,
IRIX, AmigaOS などでもコンパイルできました。注意:異なったタイプの Unix
システム上で生成されたバイナリパッケージは互換性を持っていないでしょう。
  
上記は RPM パッケージをインストールするのに最低限必要なものです。
ソースから RPM パッケージを作成するならば、
一般的にパッケージを作成するのに必要なもの、たとえば
gcc や make といったもの一式も必要になるでしょう。


<!-- 
<sect>Using RPM
<p>
In its simplest form, RPM can be used to install packages:
<tscreen><verb>
        rpm -i foobar-1.0-1.i386.rpm
</verb></tscreen>
The next simplest command is to uninstall a package:
<tscreen><verb>
        rpm -e foobar
</verb></tscreen>
<p>
One of the more complex but <em/highly/ useful commands allows you
to install packages via FTP.  If you are connected to the net
and want to install a new package, all you need to do is specify the
file with a valid URL, like so:
<tscreen><verb>
        rpm -i ftp://ftp.pht.com/pub/linux/redhat/rh-2.0-beta/RPMS/foobar-1.0-1.i386.rpm
</verb></tscreen>
<p>
Please note, that RPM will now query and/or install via FTP.
<p>
While these are simple commands, rpm can be used in a multitude
of ways as seen from the <tt/Usage/ message:
<tscreen><verb>
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}
</verb></tscreen>

You can find more details on what those options do in the RPM man
page.

-->
<sect>RPM の使用
<p>
RPM を使ってパッケージをインストールするのは簡単です。

<tscreen>
rpm -i foobar-1.0-1.i386.rpm
</tscreen>

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

<tscreen>
rpm -e foobar
</tscreen> 

ちょっと複雑になりますが、とても便利な使い方のひとつに、FTP を介してパッケージ
をインストールすることがあります。 もしネットワークに接続しており、
新しいパッケージをインストールしたいのならば、以下のように
正しい URL でファイル名を明記すればよいのです。
<tscreen>
rpm -i ftp://ftp.pht.com/pub/linux/redhat/rh-2.0-beta/RPMS/foobar-1.0-1.i386.rpm
</tscreen>

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

<tscreen>
<verb>
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}

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

<!-- 
<sect>Now what can I <em/really/ do with RPM?
<p>
RPM is a very useful tool and, as you can see, has several options.
The best way to make sense of them is to look at some examples.  I covered
simple install/uninstall above, so here are some more examples:
<itemize>
<item>Let's say you delete some files by accident, but you aren't sure
what you deleted.  If you want to verify your entire system and see what
might be missing, you would do:
<tscreen><verb>
rpm -Va
</verb></tscreen>
<item>Let's say you run across a file that you don't recognize.  To find
out which package owns it, you would do:
<tscreen><verb>rpm -qf /usr/X11R6/bin/xjewel
</verb></tscreen>
The output would be:
<tscreen><verb>xjewel-1.6-1</verb></tscreen>
<item>You find a new koules RPM, but you don't know what it is.  To find out
some information on it, do:
<tscreen><verb>rpm -qpi koules-1.2-2.i386.rpm</verb></tscreen>
The output would be:
<tscreen><verb>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.
</verb></tscreen>
<item>Now you want to see what files the koules RPM installs.  You would do:
<tscreen><verb>rpm -qpl koules-1.2-2.i386.rpm</verb></tscreen>
The output is:
<tscreen><verb>
/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
</verb></tscreen>
</itemize>
<p>
These are just several examples.  More creative ones can be thought of
really easy once you are familiar with RPM.
-->
<sect>現在 RPM で実際にできること
<p>
RPM はとても有益なツールで、ご存知の通りいくつかのオプションがあります。
それらの意味を理解するために一番の方法はいくつかの例を見る事です。これま
でに 簡単なインストール(アンインストール)の説明をしましたので、ここでは
いくつかの例を示します。

<itemize>
<item>アクシデントによっていくつかのファイルを消去してしまいしかも何を消去
したのか不確かであるとしましょう。もし全システムに照合し何を失った
かを知りたいならば、以下のようにすれば大丈夫です。
<tscreen>
rpm -Va
</tscreen>
<item>見覚えのないファイルを偶然発見したとしましょう。それはどのパッケー
ジのものであるかを見つけるために、以下のようにすれば大丈夫です。
<tscreen>
rpm -qf /usr/X11R6/bin/xjewel
</tscreen>
その出力は以下のようになります。
<tscreen>
xjewel-1.6-1
</tscreen>
<item>新しい koules RPM を見つけたが、それが何であるか知らない時には、以
下のようにすれば何か情報が得られます。
<tscreen>
rpm -qpi koules-1.2-2.i386.rpm
</tscreen>
その出力は以下のようになります。
<tscreen>
<verb>
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.
</verb>
</tscreen>
<item>インストールする koules RPM にはどのようなファイルが含まれるか知りた
い時には以下のようにしてください。
<tscreen>
rpm -qpl koules-1.2-2.i386.rpm
</tscreen>
その出力は以下のようになります。
<tscreen>
<verb>
/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
</verb>
</tscreen>
これらはほんの数例です。一度 RPM に親しめばより創造的な事を簡単に思
いつく事ができます。
</itemize>

<!-- 
<sect>Building RPMs

<p>

Building RPMs is fairly easy to do, especially if you can get the
software you are trying to package to build on its own.  

The basic procedure to build an RPM is as follows:
<itemize>
<item>Make sure your <tt>/etc/rpmrc</> is setup for your system.
<item>Get the source code you are building the RPM for to build
on your system.
<item>Make a patch of any changes you had to make to the sources to get
them to build properly.
<item>Make a spec file for the package.
<item>Make sure everything is in its proper place.
<item>Build the package using RPM.
</itemize>

Under normal operation, RPM builds both binary and source packages.
-->
<sect>RPM パッケージの作成
<p>
RPM パッケージの作成は全く簡単です、特に作成しようとしている
ソフトウェアを手に入れられるならなおさらです。

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

<itemize>
<item>あなたのシステムに適合するように /etc/rpmrc を確実に設定します。
<item>あなたのシステムで RPM を作成するためにソースコードを手に入れます。
<item>正しく作成するために必要なソースへの変更をパッチにします
<item>パッケージのための spec ファイルを作成します。
<item>全ての物が正しい場所におかれている事を確認します。
<item>RPM を用いてパッケージを作成します。
</itemize>

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

<!-- 
<sect1>The rpmrc File

<p>

Right now, the only configuration of RPM is available via the
<tt>/etc/rpmrc</> file.  An example one looks like:
<tscreen><verb>
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

</verb></tscreen>

The <tt>require_vendor</> line causes RPM to require that it find 
a vendor line.  This can come from the <tt>/etc/rpmrc</> or from the
header of the spec file itself.  To turn this off, change the number to
<tt/0/.  The same holds true for the <tt>require_distribution</> and
<tt>require_group</> lines.

The next line is the <tt>distribution</> line.  You can define that here
or later in the header of the spec file.  When building for a particular
distribution, it's a good idea to make sure this line is correct, even though
it is not required.  The <tt>vendor</>  line works much the same way, but
can be anything (ie. Joe's Software and Rock Music Emporium).

RPM also now has support for building packages on multiple architectures.
The <tt/rpmrc/ file can hold an ``optflags'' variable for building things
that require architecture specific flags when building.  See later sections
for how to use this variable.

In addition to the above macros, there are several more.  You can use:
<tscreen><verb>
rpm -\-showrc
</verb></tscreen>
to find out how your tags are set and what all the available flags are.
-->
<sect1>rpmrc ファイル
<p>
現在、RPM の設定は /etc/rpmrc ファイルのみが有効です。例えば以下のよ
うになります。
&lsqb;訳注、デフォルトとして、/usr/lib/rpmrc というものがあり、
個人の設定ファイルとして個人のホームディレクトリに .rpmrc を置くこともできます。&rsqb;
<tscreen>
<verb>
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
</verb>
</tscreen>

require_vendor の行は /etc/rpmrc もしくは spec ファイルのヘッダから 
vendor の行を探そうとします。これを無効にするには、ナンバーを 0 に変
えて下さい。require_distribution と require_group の行も同様です。

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

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

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

<tscreen>
rpm --showrc
</tscreen>

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

<!-- 
<sect1>The Spec File
<p>
We'll begin with discussion of the spec file.  Spec files are required
to build a package.  The spec file is a description of the software 
along with instructions on how to build it and a file list for
all the binaries that get installed.
<p>
You'll want to name your spec file according to a standard convention.
It should be the package name-dash-version number-dash-release number-dot-spec.
<p>
Here is a small spec file (vim-3.0-1.spec):
<tscreen><verb>
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
</verb></tscreen>
<sect1>The Header
<p>
The header has some standard fields in it that you need to fill in.  There
are a few caveats as well.  The fields must be filled in as follows:
<itemize>
        <item><tt/Summary:/ This is a one line description of the package.
        <item><tt/Name:/ This must be the name string from the rpm filename you 
plan to use.
        <item><tt/Version:/ This must be the version string from the rpm filename
you plan to use.
        <item><tt/Release:/ This is the release number for a package of the same
version (ie. if we make a package and find it to be slightly broken and
need to make it again, the next package would be release number 2).
        <item><tt/Icon:/ This is the name of the icon file for use by
other high level installation tools (like Red Hat's ``glint'').  It must
be a gif and resides in the SOURCES directory.
        <item><tt/Source:/ This line points at the HOME location of the pristine
source file.  It is used if you ever want to get the source again or 
check for newer versions.  Caveat:  The filename in this line MUST match
the filename you have on your own system (ie. don't download the source
file and change its name).  You can also specify more than one source file
using lines like:
<tscreen><verb>
Source0: blah-0.tar.gz
Source1: blah-1.tar.gz
Source2: fooblah.tar.gz
</verb></tscreen>
These files would go in the <tt/SOURCES/ directory. (The directory
structure is discussed in a later section, "The Source Directory Tree".)
        <item><tt/Patch:/ This is the place you can find the patch if you need
to download it again.  Caveat:  The filename here must match the one
you use when you make YOUR patch.  You may also want to note that you
can have multiple patch files much as you can have multiple sources.  ]
You would have something like:
<tscreen><verb>
Patch0: blah-0.patch
Patch1: blah-1.patch
Patch2: fooblah.patch
</verb></tscreen>
These files would go in the <tt/SOURCES/ directory.
        <item><tt>Copyright:</> This line tells how a package is copyrighted.
You should use something like GPL, BSD, MIT, public domain, distributable,
or commercial.
        <item><tt/BuildRoot:/ This line allows you to specify a directory as the
``root'' for building and installing the new package.  You can use this to 
help test your package before having it installed on your machine.
        <item><tt/Group:/ This line is used to tell high level installation
programs (such as Red Hat's ``glint'') where to place this particular
program in its hierarchical structure.  The group tree currently looks
something like this:
<tscreen><verb>
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
</verb></tscreen>

        <item><tt/%description/  It's not really a header item, but
should be described with the rest of the header.  You need one description
tag per package and/or subpackage.  This is a multi-line field that should
be used to give a comprehensive description of the package.

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

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

ここに簡単な spec ファイルがあります。(vim-3.0-1.spec)
&lsqb;訳注、vim-3.0-1.spec とありますが、これはeject-1.4-3.spec でしょう。&rsqb;

<tscreen>
<verb>
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
</verb>
</tscreen>

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

<itemize>
<item>Summary: これは一行のパッケージの説明です。
<item>Name: これは使おうとしている rpm ファイル名からの文字列でなけれ
ばなりません。
<item>Version: これは使おうとしている rpm ファイル名からのバージョン番号
でなければなりません。
<item>Release: これは同じバージョンのパッケージのためのリリース番号です。
(例えば、パッケージを作成しそれがわずかに壊れているのを発見し再度
作成する必要があるならば、次のパッケージのリリース番号は2となります。)
<item>Icon: これは他の高レベルなインストールツール(Red Hat の "glint"の様
な)を用いる為のアイコン名です。それはgif ファイルで SOURCES ディレ
クトリに置かなければなりません。
<item>Source: この行は元のソースファイルのホームロケーションを指します。
再びソースファイルを手に入れたいとか新しいバージョンをチェックした
い時に使われます。注意：この行のファイル名とあなたのシステム上に持
つファイル名は一致していなければなりません。(例えば、ソースファイ
ルをダウンロードしその名前は変えてはいけません。) 一つ以上のソース
ファイルを明記したい時は以下のように書きます。
<tscreen>
<verb>
Source0: blah-0.tar.gz
Source1: blah-1.tar.gz
Source2: fooblah.tar.gz
</verb>
</tscreen>
これらのファイルは SOURCES ディレクトリに置きます。(ディレクトリ構
造は後の節  "ソース ディレクトリ ツリー" で扱います。)
<item>・Patch: これは再びパッチをダウンロードする必要がある時にそれを見つ
ける事のできる場所です。注意：あなたが自分で作成したパッチを作る
時ファイル名は使う名前と一致しなければなりません。例えば以下の
ようです。
<tscreen>
<verb>
Patch0: blah-0.patch
Patch1: blah-1.patch
Patch2: fooblah.patch
</verb>
</tscreen>
これらのファイルは SOURCES ディレクトリに置きます。
<item>Copyright: この行はパッケージがどのような著作権であるか表示します。
GPL、BSD、MIT、public domain、distributable、commercial の様なもの
を使うべきです。
<item>BuildRoot: この行は新しいパッケージを作成、インストールするための
"ルート" のディレクトリを明記します。あなたのマシーンにインストー
ルする前にパッケージをテストするのを助けるために使う事ができます。
&lsqb;訳注、ここに記述するだけでは、作成およびテストはできません。
詳しくは、RPM-BUILD-HOWTO を読むと良いでしょう。&rsqb;
<item>Group: この行は高レベルなインストールプログラム(Red Hat の "glint" 
のような)に階層構造の中でこのプログラムがどこに属するのかを
明示するためにつかわれます。現在の グループ ツリーは以下のようになっ
ています。&lsqb;訳注、日本向けに Extensions/Japanese というものあります。&rsqb;
<tscreen>
<verb>
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
</verb>
</tscreen>
<item>%description これは本当はヘッダの項目ではありません、しかしヘッダ
の中に記述されるべきです。パッケージと(もしくは)サブパッケージに一
つの説明(description)のタグが必要です。これはパッケージの包括的な
説明を与えるために使われるべき複数行のフィールドです。
</itemize>

<!-- 
<sect1>Prep
<p>
This is the second section in the spec file.  It is used to get the
sources ready to build.  Here you need to do anything necessary to
get the sources patched and setup like they need to be setup to
do a <tt/make/.
<p>
One thing to note:  Each of these sections is really just a place to
execute shell scripts.  You could simply make an <tt/sh/ script and put it
after the <tt/&percnt;prep/ tag to unpack and patch your sources.  We have
made macros to aid in this, however.
<p>
The first of these macros is the <tt/&percnt;setup/ macro.  In its simplest form
(no command line options), it simply unpacks the sources and <tt/cd/'s into
the source directory.  It also takes the following options:

<itemize>
        <item><tt/-n name/ will set the name of the build directory to the listed
<tt/name/.  The default is <tt/&dollar;NAME-&dollar;VERSION/.  Other possibilities 
include <tt/&dollar;NAME/, <tt/&dollar;{NAME}&dollar;{VERSION}/, or whatever the main tar file
uses.  (Please note that these ``&dollar;'' variables are <em/not/ real 
variables available within the spec file.  They are really just used here
in place of a sample name.  You need to use the real name and version in
your package, not a variable.)
        <item><tt/-c/ will create and cd to the named directory <em/before/ doing
the untar.
        <item><tt/-b &num;/ will untar Source&num; <em/before/ cd'ing into the directory
(and this makes no sense with <tt/-c/ so don't do it).  This is only
useful with multiple source files.
        <item><tt/-a &num;/ will untar Source&num; <em/after/ cd'ing into the directory.
        <item><tt/-T/ This option overrides the default action of untarring the
Source and requires a <tt/-b 0/ or <tt/-a 0/ to get the main source file
untarred.  You need this when there are secondary sources.
        <item><tt/-D/ Do <em/not/ delete the directory before unpacking.
This is only useful where you have more than one setup macro.  It should
<em/only/ be used in setup macros <em/after/ the first one (but never
in the first one).
</itemize>
<p>
The next of the available macros is the <tt/%patch/ macro.  This macro
helps automate the process of applying patches to the sources.  It takes
several options, listed below:
<itemize>
        <item><tt/&num;/ will apply Patch&num; as the patch file.
        <item><tt/-p &num;/ specifies the number of directories to strip
for the patch(1) command.
        <item><tt/-P/ The default action is to apply <tt/Patch/ (or
<tt/Patch0/).  This flag inhibits the default action and
will require a <tt/0/ to get the main source file untarred.  This option
is useful in a second (or later) <tt/&percnt;patch/ macro that required a different
number than the first macro.
        <item> You can also do <tt/&percnt;patch&num;/ instead of doing
the real command: <tt/&percnt;patch &num; -P/
</itemize>
<p>
That should be all the macros you need.  After you have those right, you
can also do any other setup you need to do via <tt/sh/ type scripting.
Anything you include up until the <tt/&percnt;build/ macro (discussed in the
next section) is executed via <tt/sh/.  Look at the example above for
the types of things you might want to do here.
-->
<sect1>Prep
<p>
これは、spec ファイル中の2番目のセクションです。作成用に準備するソースを得る
ために使われます。ここで、パッチの当てられたソースを得るために必要な
事をし make するために必要な準備をします。

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

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

<itemize>
<item>-n name は列挙された name に作成ディレクトリの名前をセットしま
す。デフォルトは &dollar;NAME-VERSION です。他の可能性として &dollar;NAME、
&dollar;{NAME}&dollar;{VERION}、メインの tar ファイルが用いているものです。
(これらの "&dollar;" 変数は spec ファイル中の本当の変数でない事に注意して
下さい。これらは参考のためにここで使われたものです。実際には変数ではな
くパッケージ中の本当の名前とバージョンを使う必要があります。)
<item>-c は tar ファイルを解凍する前に名付けられたディレクトリを作りそこ
に cd します。
<item>-b &num; はディレクトリに cd する前に Source&num; を 解凍(untar)します。
(これは -c オプションと一緒に用いるのは意味がありません、しないで
下さい。) これは複数のソースファイルがある時のみ役に立ちます。
<item>-a &num; は ディレクトリに cd した後に Source&num; を解凍(untar)します。
<item>-T このオプションはソース解凍(untar)のデフォルト動作を無効にします。
解凍(untar)されたメインのソースファイルを得るために -b 0 もしくは 
-a 0 を必要とします。2つめのソースがある時にこれを必要とします。
<item>-D は解凍する前にディレクトリを消去しません。これは setup マクロが
複数ある時のみ有用です。最初の setup マクロの後の setup マクロでの
み使うべきです。(決して最初の setup マクロで使わないで下さい。)
</itemize>
次に有益なマクロは %patch マクロです。このマクロはソースにパッチを当
てる課程の自動化を助けます。いくつかのオプションがありそれは以下の通
りです。
<itemize>
<item>&num; はパッチファイルとして Patch&num; を利用します。
<item>-p &num; patch(1) コマンドのための取り除くディレクトリの数を明記します。
<item>-P デフォルトの動作では Patch (もしくは Patch0)を当てます。このフラ
グはデフォルトの動作を禁止するので解凍(untar)されたソースファイルを
得るために 0 を必要とします。このオプションは最初のマクロと異なる大
きい番号を求められる2番目(もしくはそれ以降)の %patch マクロで有用で
す。
<item>本来の %patch &num; -p コマンドの代わりに %patch&num; も使えます。	
</itemize>
以上で必要なマクロは全部です。これらを正しく記述した後に、sh スクリ
プトを用いて他のあらゆる必要なセットアップをする事もできます。%build 
マクロ(これは次節で説明します。)が sh を経由して実行されるまで何でも
含められます。ここで行いたい事の形は上記の例を見て下さい。

<!-- 
<sect1>Build
<p>
There aren't really any macros for this section.  You should just put
any commands here that you would need to use to build the software
once you had untarred the source, patched it, and cd'ed into the directory.
This is just another set of commands passed to <tt/sh/, so any legal
<tt/sh/ commands can go here (including comments).  <bf/Your current 
working directory is reset in each of these sections to the toplevel
of the source directory/, so keep that in mind.  You can <tt/cd/ into
subdirectories if necessary.
-->
<sect1>Build
<p>
このセクションにはマクロはありません。ソースを解凍(untar)し、パッチを当て、
ディレクトリに cd したならここでは単にソフトウェアを作成するために必
要なコマンドを記述して下さい。これは単に sh に渡す他のコマンドの集ま
りなので、どんな合法的な sh のコマンド(コメントを含む)でもここで実行
できます。&lsqb;訳注：これはシェルの組み込みコマンドの事だけをいっている
のではありません。&rsqb;これらのセクションの各々で作業ディレクトリはソー
スディレクトリの一番上にリセットされますのでそれを覚えておいて下さい。
もし必要ならばサブディレクトリに cd して下さい。

<!-- 
<sect1>Install
<p>
There aren't really any macros here, either.  You basically just want to
put whatever commands here that are necessary to install.  If you have
<tt/make install/ available to you in the package you are building, put
that here.  If not, you can either patch the makefile for a <tt/make
install/ and just do a <tt/make install/ here, or you can hand install
them here with <tt/sh/ commands.  You can consider your current 
directory to be the toplevel of the source directory.
-->
<sect1>Install
<p>
ここにもマクロはありません。基本的にここにインストールに必要なコマン
ドなら何でも置けます。作成したパッケージ中で make install が有効なら、
ここに置きます。そうでないのなら、make install の為の makefile への
パッチを当て、make install をするか、sh コマンドによって手動でインス
トールする事もできます。現在の作業ディレクトリがソースディレクト
リのトップレベルである事を考慮して下さい。

<!-- 
<sect1>Optional pre and post Install/Uninstall Scripts
<p>
You can put scripts in that get run before and after the installation
and uninstallation of binary packages.  A main reason for this is
to do things like run <tt/ldconfig/ after installing or removing
packages that contain shared libraries.  The macros for each of the
scripts is as follows:
<itemize>
<item><tt/&percnt;pre/ is the macro to do pre-install scripts.
<item><tt/&percnt;post/ is the macro to do post-install scripts.
<item><tt/&percnt;preun/ is the macro to do pre-uninstall scripts.
<item><tt/&percnt;postun/ is the macro to do post-uninstall scripts.
</itemize>
<p>
The contents of these sections should just be any <tt/sh/ style 
script, though you do <em/not/ need the <tt>&num;!/bin/sh</>.
-->
<sect1>pre ,post インストール / アンインストール スクリプト (任意)
<p>
バイナリパッケージのインストール / アンインストール を行う前と後に実
行するスクリプトをここに置く事ができます。シェアードライブラリを含む
パッケージを インストールもしくはアンインストールした後に ldconfig 
を実行するような事をするためにこのタグがあります。以下に各々のスクリ
プトのためのマクロがあります。
<itemize>
<item>%pre はインストールする前のスクリプトためのマクロです。
<item>%post はインストールした後のスクリプトのためのマクロです。
<item>%preun はアンインストールする前のスクリプトのためのマクロです。
<item>%postun は アンインストールした後のスクリプトのためのマクロです。
</itemize>

<!-- 
<sect1>Files
<p>
This is the section where you <em/must/ list the files for
the binary package.  RPM has no way to know what binaries get installed
as a result of <tt/make install/.  There is <em/NO/ way to do this.
Some have suggested doing a <tt/find/ before and after the package
install.  With a multiuser system, this is unacceptable as other files
may be created during a package building process that have nothing to
do with the package itself.  
<p>
There are some macros available to do some special things as well.  They
are listed and described here:
<itemize>
<item><tt/&percnt;doc/ is used to mark documentation in the source
package that you want installed in a binary install.  The documents 
will be installed in <tt>/usr/doc/&dollar;NAME-&dollar;VERSION-&dollar;RELEASE</>.  You can list multiple documents on the command line with this
macro, or you can list them all separately using a macro for each of them.
<item><tt/&percnt;config/ is used to mark configuration files in a package.
This includes files like sendmail.cf, passwd, etc.  If you later uninstall
a package containing config files, any unchanged files will be removed and
any changed files will get moved to their old name with a <tt/.rpmsave/
appended to the filename.  You can list multiple files with this macro
as well.
<item><tt/&percnt;dir/ marks a single directory in a file list to be 
included as being owned by a package.  By default, if you list a directory
name <em/WITHOUT/ a <tt/&percnt;dir/ macro, <em/EVERYTHING/ in that 
directory is included in the file list and later installed as part of
that package.  
<item><tt/&percnt;files -f &lt;filename&gt;/ will allow you to list your
files in some arbitrary file within the build directory of the sources.
This is nice in cases where you have a package that can build it's own
filelist.  You then just include that filelist here and you don't have
to specifically list the files.
</itemize>
<p>
The biggest caveat in the file list is listing directories.  If you list
<tt>/usr/bin</> by accident, your binary package will contain <em/every/ file
in <tt>/usr/bin</> on your system. 
-->
<sect1>Files
<p>
このセクションはバイナリパッケージのためのファイルの一覧を表示しなければなり
ません。RPM は make install の結果どのバイナリがインストールされたの
か知る方法がないためです。これをする方法はありません! パッケージのイ
ンストール前と後に find を実行すればよいのではないかと疑問に思う人も
いるかもしれません。マルチユーザーシステムにおいて、パッケージと関係
のないファイルがパッケージを作成している課程の間に作られているかもし
れないのでこれは受け入れられません。

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

<itemize>
<item>&percnt;doc はバイナリをインストールする際にインストールしたいソースパッ
ケージ中のドキュメントに印を付けるのに使われます。ドキュメントは
/usr/doc/&dollar;NAME-&dollar;VERSION-&dollar;RELEASE にインストールされ
ます。このマクロを使ってコマンドライン上で複数のドキュメントの一覧を列挙
するか、各ドキュメントごとにマクロを使って別々に列挙することができます。
<item>&percnt;config はパッケージ中の設定ファイルに印を付けるのに使われます。こ
れは sendmail.cf、passwd などのようなものを含みます。もし後に設定
ファイルを含むパッケージをアンインストールするならば、変更されてい
ないファイルは削除され、変更されたファイルはもとファイル名に 
.rpmsave という拡張子を付加されたものに名前が変更されます。
このマクロでも同時に複数のファイルの一覧を列挙できます。
<item>&percnt;dir パッケージによって所有され含まれるファイル一覧中の単一のディ
レクトリに印を付けます。デフォルトでは、&percnt;dir マクロを使わずにディ
レクトリ名を表示したなら、そのディレクトリ中の全てがファイル一覧に
含まれそして後にそのパッケージの一部としてインストールされます。
<item>&percnt;files -f &lt;filename&gt; はソースの作成ディレクトリ中の任意のファイル
を リストに加える事ができます。これはパッケージ自身のファイルリス
トを作成する事ができるパッケージがある場合に便利です。
その時ここにそのファイルリストを含めます、そして特にファイルを一覧
表示してはなりません。
</itemize>

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

<!-- 
<sect1>Building It
<p>
<sect2>The Source Directory Tree
<p>
The first thing you need is a properly configured build tree.
This is configurable using the <tt>/etc/rpmrc</> file.  Most people
will just use <tt>/usr/src</>.
<p>
You may need to create the following directories to make a build
tree:
<itemize>
<item><tt/BUILD/ is the directory where all building occurs by RPM.
You don't have to do your test building anywhere in particular, but
this is where RPM will do it's building.
<item><tt/SOURCES/ is the directory where you should put your 
original source tar files and your patches.  This is where RPM will look
by default.
<item><tt/SPECS/ is the directory where all spec files should go.
<item><tt/RPMS/ is where RPM will put all binary RPMs when built.
<item><tt/SRPMS/ is where all source RPMs will be put.
</itemize>
<p>
-->
<sect1>作成
<p>
<sect2>ソースディレクトリ ツリー
<p>
まず最初に必要な事は、きちんと設定された作成ディレクトリツリーです。
これは /etc/rpmrc ファイルを用いて設定可能です。多くの人々は 
/usr/src を使うでしょう。

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

<itemize>
<item>BUILD は RPM により全ての作成が行われるディレクトリです。特に他の
場所で作成のテストを行う必要はありませんが、ここは RPM が作成する
用いるところです。
<item>SOURCES はオリジナルのソース(tar)ファイルとパッチを置くディレクト
リです。ここは、RPM がデフォルトで探すディレクトリです。
<item>SPECS は全ての spec ファイルを置くディレクトリです。
<item>RPMS は RPM が作成したバイナリ RPM パッケージを置くディレクトリです
<item>SRPMS は 全てのソース RPM パッケージを置くディレクトリです。
</itemize>

<!-- 
<sect2>Test Building
<p>
The first thing you'll probably want to to is get the source to
build cleanly without using RPM.  To do this, unpack the sources,
and change the directory name to &dollar;NAME.orig.  Then unpack the
source again.  Use this source to build from.  Go into the source
directory and follow the instructions to build it.  If you have to
edit things, you'll need a patch.  Once you get it to build, clean
the source directory.  Make sure and remove any files that get made
from a <tt>configure</> script.  Then <tt/cd/ back out of the source directory
to its parent.  Then you'll do something like:
<tscreen><verb>
        diff -uNr dirname.orig dirname > ../SOURCES/dirname-linux.patch
</verb></tscreen>
This will create a patch for you that you can use in your spec file.
Note that the ``linux'' that you see in the patch name is just an 
identifier.  You might want to use something more descriptive like
``config'' or ``bugs'' to describe <em/why/ you had to make a patch.
It's also a good idea to look at the patch file you are creating before
using it to make sure no binaries were included by accident.
<p>
-->
<sect2>作成テスト
<p>
おそらく最初にしたいことは、RPM を用いずに作成するためのソースツリー
を得ることでしょう。これをするために、ソースを解凍し、ディレクトリ名
を &dollar;NAME.orig に変更して下さい。そしてもう一度ソースを解凍して下さい。
そしてこのソースを作成に使用して下さい。ソースディレクトリに入り作成
するための指示にしたがって下さい。もし何か編集をしなければならないな
ら、パッチが必要となります。一度それを作るためにソースディレクトリを
きれいにします。./configure スクリプトにより生成されたファイルを確認
し削除します。&lsqb;訳注：要するに、いわゆる make 一発状態にすれば良いと
いう事です。&rsqb;
そして、ソースディレクトリの親ディレクトリに cd します。
以下のようにします。

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

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

<!-- 
<sect2>Generating the File List
<p>
Now that you have source that will build and you know how to do it, 
build it and install it.  Look at the output of the install sequence and
build your file list from that to use in the spec file.  We usually 
build the spec file in parallel with all of these steps.  You can 
create the initial one and fill in the easy parts, and then fill in
the other steps as you go.
<p>
<sect2>Building the Package with RPM
<p>
Once you have a spec file, you are ready to try and build your
package.  The most useful way to do it is with a command like the
following:
<p>
<tscreen><verb>
        rpm -ba foobar-1.0.spec
</verb></tscreen>
<p>
There are other options useful with the <tt/-b/ switch as well:
<itemize>
<item><tt/p/ means just run the <tt/prep/ section of the specfile.
<item><tt/l/ is a list check that does some checks on <tt/&percnt;files/.
<item><tt/c/ do a prep and compile.  This is useful when you are unsure of
whether your source will build at all.  It seems useless because you might
want to just keep playing with the source itself until it builds and then
start using RPM, but once you become accustomed to using RPM you will 
find instances when you will use it.
<item><tt/i/ do a prep, compile, and install.
<item><tt/b/ prep, compile, install, and build a binary package only.
<item><tt/a/ build it all (both source and binary packages).
</itemize>
There are several modifiers to the <tt/-b/ switch.  They are as follows:
<itemize>
<item><tt/-\-short-circuit/ will skip straight to a specified stage (can
only be used with c and i).
<item><tt/-\-clean/ removes the build tree when done.
<item><tt/-\-keep-temps/ will keep all the temp files and scripts that were
made in /tmp.  You can actually see what files were created in /tmp using
the <tt/-v/ option.
<item><tt/-\-test/ does not execute any real stages, but does keep-temp.
</itemize>
-->
<sect2>ファイルリストの生成
<p>
作成するためのソースを手にいれ、それをどうやって作成するかわかったな
らば、作成しインストールします。インストールの結果の出力から spec ファ
イルで用いるためのファイルリストを作成します。私たちは、たいてい全て
のステップで並行して spec ファイルを作成しています。最初のファイルリ
ストを作成して簡単な部分を書き込み、そして順を追って埋めていきます。

<sect2>RPM を用いたパッケージの作成
<p>
spec ファイルを書き終えたなら、パッケージを作成する準備ができました。
もっとも有効な方法は、以下のようなコマンドを使うことです。
<tscreen>
rpm -ba foobar-1.0.spec
</tscreen>
-b スイッチには以下のような有用なオプションがあります。

<itemize>
<item>p は spec ファイルの prep セクションだけを実行します。
<item>l は %files のリストをチェックします。
<item>c は prep セクションを実行し コンパイルを行います。これはソースが
完全に構築できるものかどうか不確実な時に役立ちます。ソースを構築しそ
れから RPM を使いはじめるまでは、ソースのみで作業し続けたいでしょ
うから、役に立たないと思われます。しかし一旦 RPM を使うのに慣れて
しまえば、それを使う例が見つかるでしょう。
&lsqb;訳注、%Build セクションの有効性を確認するぐらいでしょう。&rsqb;
<item>i は prep セクションを実行し、コンパイル インストールを行います。
<item>b は prep セクションを実行し、コンパイル インストールを行い、バイ
ナリパッケージのみを作成します。
<item>a は全てを作成します。(ソースとバイナリのパッケージの両方)
</itemize>

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

<itemize>
<item>--short-circuit は指定された処理を飛ばします。(c と i でのみ使用
できます。)
<item> --clean はパッケージの作成が終った後に作成したディレクトリツリー
を消去します。
<item> --keep-temps は /tmp 以下に作られた全ての一時ファイルとスクリプト
を保存します。実は -v オプションを用いることにより /tmp に作られた
ファイルを見ることができます。
<item>--test は実際にはどの処理も実行はしませんが、keep-temp は行います。
</itemize>

<!-- 
<sect1>Testing It
<p>
Once you have a source and binary rpm for your package, you need to
test it.  The easiest and best way is to use a totally different machine
from the one you are building on to test.  After all, you've just
done a lot of <tt/make install/'s on your own machine, so it should
be installed fairly well.  
<p>
You can do an <tt/rpm -u packagename/ on the package to test, but that
can be deceiving because in building the package, you did a <tt/make install/.
If you left something out of your file list, it will not get uninstalled.
You'll then reinstall the binary package and your system will be complete
again, but your rpm still isn't.  Make sure and keep in mind that just
because you do a <tt/rpm -ba package/, most people installing your package will
just be doing the <tt/rpm -i package/.  Make sure you don't do anything
in the <tt/build/ or <tt/install/ sections that will need to be done when
the binaries are installed by themselves.  
<p>
-->
<sect1>テスト
<p>
いったん、ソース及びバイナリの rpm パッケージを作成したら、それをテ
ストする必要があります。最も簡単で良い方法は、パッケージを作成したマ
シンと全く異なったマシン上でテストする事です。なぜなら、あなたのマシ
ン上で何度も make install をしているので、きちんとインストールされる
はずだからです。

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

<!-- 
<sect1>What to do with your new RPMs
<p>
Once you've made your own RPM of something (assuming its something
that hasn't already been RPM'ed), you can contribute your work to 
others (also assuming you RPM'ed something freely distributable).  To
do so, you'll want to upload it to <url url="ftp://ftp.redhat.com"
name="ftp.redhat.com">.
-->
<sect1>新しく作成した RPM パッケージをどうすれば良いか。
<p>
いったん、あなたが RPM パッケージを作成したなら(すでに何か RPM 化し
たと仮定します)、あなたの作成したパッケージで他の人に貢献する事がで
きます(作成した RPM パッケージが自由に配布可能なものとします)。そう
するために、ftp.redhat.com にアップロードしてください。
<url url=
"ftp://ftp.redhat.com">

<!-- 
<sect1>What Now?
<p>
Please see the above sections on Testing and What to do with new RPMs.
We want all the RPMs available we can get, and we want them to be good
RPMs.  Please take the time to test them well, and then take the time
to upload them for everyone's benefit.  Also, <em/please/ make sure
you are only uploading <em/freely available software/.  Commercial
software and shareware should <em/not/ be uploaded unless they have
a copyright expressly stating that this is allowed.  This includes
Netscape software, ssh, pgp, etc.
-->
<sect1>What Now?
<p>
新しい RPM パッケージですることとテストに関しては上記のセクションを
見てください。私達は 取得可能な 全ての RPM パッケージを募集していま
す。そして、それらが素晴らしい RPM パッケージであることを望んでいま
す。作成したパッケージをよく時間をかけてテストしてください。そして、
万人の利益のためにそれをアップロードするために時間をかけてください。
同様に、自由に配布できるソフトウェアのみをアップロードするようにして
ください。商用ソフトウェア及びシェアウェアはそれらの著作権がはっきり
と自由に配布する事が許される事を言及してない限りアップロードすべきで
はありません。これには、Netscape ソフトウェア、ssh、pgp 等が含まれま
す。

<!-- 
<sect>Multi-architectural RPM Building
<p>
RPM can now be used to build packages for the Intel i386, the Digital
Alpha running Linux, and the Sparc.  It has been reported to work
on SGI's and HP workstations as well.  There are several features that
make building packages on all platforms easy.  The first of these is
the ``optflags'' directive in the <tt>/etc/rpmrc</>.  It can be used to
set flags used when building software to architecture specific values.
Another feature is the ``arch'' macros in the spec file.  They can be used
to do different things depending on the architecture you are building on.
Another feature is the ``Exclude'' directive in the header.  
-->
<sect>マルチ アーキテクチャ用 RPM パッケージの作成
<p>
RPM は現在 Intel i386、Degital Alpha、Sparc 用にパッケージ
を作成するために使う事ができます。SGI と HP のワークステーション上で
も同様に動く事が報告されています。全てのプラットフォーム上で簡単に
パッケージを作成するための特徴がいくつかあります。まず第一に 
/etc/rpmrc の中の "optflag" の指示です。それはソフトウェアを作成する
時に使われるフラグをアーキテクチャ特有の値に設定するために使う事がで
きます。他の機能として spec ファイル中の "arch" マクロがあります。
それは作成するアーキテクチャに依存する異なる作業をするために使う事が
できます。他に、ヘッダ中の "Exclude" の指示です。

<!-- 
<sect1>Sample spec File
<p>
The following is part of the spec file for the ``fileutils'' package.  It is
setup to build on both the Alpha and the Intel.
<tscreen><verb>
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*

.
.
.

</verb></tscreen>
-->
<sect1>サンプル spec ファイル
<p>
以下は "fileutils" パッケージの spec ファイルの一部です。
Alpha と Intel 向けの両方を作成するための構成です。
<tscreen>
<verb>
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*
</verb>
</tscreen>

<!-- 
<sect1>Optflags
<p>
In this example, you see how the ``optflags'' directive is used from
the <tt>/etc/rpmrc</>.  Depending on which architecture you are building
on, the proper value is given to <tt/RPM_OPT_FLAGS/.  You must patch
the Makefile for your package to use this variable in place of the
normal directives you might use (like <tt/-m486/ and <tt/-O2/).  You can 
get a better feel for what needs to be done by installing this 
source package and then unpacking the source and examine the Makefile.
Then look at the patch for the Makefile and see what changes must be
made.  
-->
<sect1>optflags
<p>
この例では、どのように /etc/rpmrc 中の "optflags" の指示が使われてい
るか分かるでしょう。あなたが作成しているアーキテクチャに依存する適当
な値が RPM_OPT_FLAGS に与えられています。使用している(-m486 や -O2 
のような) 通常の指示の代わりにこの変数を用いるには、パッケージの
Makefile にパッチを当てなければなりません。
このソースパッケージをインストールすることによって必要となることをソー
スを解凍して Makefile を調べることが 良いと感じるでしょう。
その時、Makefile のためのパッチをしらべ、何を変えねばならないかを見
てください。

<!-- 
<sect1>Macros
<p>
The <tt/%ifarch/ macro is very important to all of this.  Most times you
will need to make a patch or two that is specific to one architecture
only.  In this case, RPM will allow you to apply that patch to just
one architecture only.  

In the above example, fileutils has a patch for 64 bit machines.  Obviously,
this should only be applied on the Alpha at the moment.  So, we add
an <tt/%ifarch/ macro around the 64 bit patch like so:
<tscreen><verb>
%ifarch axp
%patch1 -p1
%endif
</verb></tscreen>
This will insure that the patch is not applied on any architecture
except the alpha.
-->
<sect1>マクロ
<p>
&percnt;ifarch マクロはとても重要です。多くの場合一つのパッチもしくは特定の
アーキテクチャ用の二つのパッチを作る必要があるでしょう。このような場
合、RPM は適したアーキテクチャ用のパッチのみを当てることができます。

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

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

<!-- 
<sect1>Excluding Architectures from Packages
<p>
So that you can maintain source RPMs in one directory for all platforms,
we have implemented the ability to ``exclude'' packages from being built
on certain architectures.  This is so you can still do things like
<tscreen><verb>
rpm -\-rebuild /usr/src/SRPMS/*.rpm
</verb></tscreen>
and have the right packages build.  If you haven't yet ported an application
to a certain platform, all you have to do is add a line like:
<tscreen><verb>
ExcludeArch: axp
</verb></tscreen>
to the header of the spec file of the source package.  Then rebuild the package
on the platform that it does build on.  You'll then have a source package
that builds on an Intel and can easily be skipped on an Alpha.
-->
<sect1>パッケージから アーキテクチャを除外する
<p>
全てのプラットホームのために一つのディレクトリでソース RPM パッケー
ジをメンテナンスできるようにするために、私達はあるアーキテクチャ上で
作成されることからパッケージを"除外"するための機能を実装しました。こ
れは以下のように実行できます。
<tscreen>
rpm --rebuild /usr/src/SRPMS/*.rpm
</tscreen>
そして正しくパッケージが作成されます。もしあるプラットホーム向けにア
プリケーションを移植していないのならば、あなたがしなければならないこ
と全てはソースパッケージの spec ファイルのヘッダに以下のような一行を
付け加えることです。
<tscreen>
ExcludeArch: axp
</tscreen>
そのようにしてから、作成するプラットホーム上でパッケージを再作成して
ください。そうすれば、あなたは Intel 上で作成するためのソースパッケー
ジを手にすることになり、Alpha の部分は簡単に飛ばすことができます。

<!-- 
<sect1>Finishing Up
<p>
Using RPM to make multi-architectural packages is usually easier to do than
getting the package itself to build both places.  As more of the hard packages
get built this is getting much easier, however.  As always, the best help
when you get stuck building an RPM is to look a similar source package.
-->
<sect1>最後に
<p>
マルチ アーキテクチャ用のパッケージを作成するために RPM を用いること
はたいていパッケージを両方のアーキテクチャ上で作成するよりも簡単です。
しかしながら、作成するのがとても難しいパッケージを作成すればより簡単
になっていきます。いつものように、RPM パッケージを作成するのにつまっ
た時に最もよい助けとなることは似たようなソースパッケージを調べること
です。

<!-- 
<sect>Copyright Notice

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

&lsqb;訳者より：この部分は原文も掲載しておきます。&rsqb;
<p>
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.
</article>
