furutaka@Flux.tokai.jaeri.go.jp ishioka@PPP01.infoPepper.or.jp注意: この文書はかなり以前に書かれたものなので、 いまどきの Linux 環境にはあてはまらない箇所があります。 (JF Project)
この文書では、Red Hat Software の開発したパッケージマネージメント ツール、Redhat Package Manager (RPM) を用いたバイナリ及びソース パッケージの作成方法を解説しています。
この文書では、RPM を用いた、バイナリパッケージのインストール
及び更新方法、情報の問い合わせ方法や検証方法は解説しておりません。
これらに関しては、
RPM-HOWTO,
RPM-Tips
及び rpm(8) の man page (または
それらの翻訳)を参照して下さい。
RPM-HOWTO は、山縣 敦 <ayamagat@phys.metro-u.ac.jp>
さんが日本語に翻訳して下さいました。
rpm(8) の man page は、第一筆者が翻訳し、随時 Linux-ML 等に
流しております。
なお、この文書では、パッケージマネージャを``RPM'' と
大文字で表記し、それを用いて作られるバイナリパッケージ
(*.rpm)及びソースパッケージ(*.src.rpm)
と区別しています。
この文書の著作権は古高和禎及び石岡尚にあるものとします。
また、この文書は、GPL に従って自由に配付・利用できるもの とします。
この文書は、筆者達が package-ML における
RPM を使用したパッケージングの実験を通して得た
少ない経験及び知識をまとめたものです。
従って、筆者の誤解による誤った記述や欠落してしまっている情報が 数多くあるものと思われます。
誤りや追加すべき情報を発見なさった方は、 第一筆者 にお知らせ頂ければ、文書の更新時に訂正/追加を行なって参ります。
RPM とは、Redhat Package Manager の略で、その名の通り Red Hat Software (RHS) の Linux ディストリビューション Red Hat Linux (RHL)用に開発されたツールで、ソフトウェア のインストール、保守、パッケージングを行ないます。
しかし、RPM は RHL 以外では使えない訳ではありません。 むしろ、RHS の面々が様々な文書で言っているように、 「他のディストリビューションでも容易に使える」のです (実際、最近では、とある理由から Debian ディストリビューションで RPM のバイナリパッケージが流通されていた筈です)。 また、Red Hat 以外のディストリビューションを使用している方も RPM を容易に使用できる様に、RPM のバイナリを(RPM を用いずに) インストールする方法が(現在のところix86アーキテクチャのみ ですが)用意されています。
この節では RHL 以外の ix86 アーキテクチャ用ディストリビューション に RPM をインストールする方法を解説します。 RHL ディストリビューションを用いている方は、RPM が インストールされていますから、この節は飛ばして構いません。 (もし、使用している RPM が古いもので、この文書で説明している 機能が使いたいのに使えない、という場合は、Red Hat 自身による RPM のアップグレード法に従って下さい。)
RPM を使用するためには、
GNU cpio (version 2.4.1 以降のもの)rpm-2.2.9-1.i386.cpio.gz
Red Hat の本家ミラーサイト
KDD のミラーお使いのシステムに既に cpio がインストール
されていても、バージョンが古い場合には
(例えば Slackware 3.0 に含まれている
``GNU cpio version 2.3'')
RPM が用いる --quiet というオプションが
備わっていないので RPM 2.2.9 と組み合わせては使用できません。
この場合は、上記ミラーサイト等から cpio も
ftp し、現在インストールされている cpio と
入れ換えておいて下さい。
必要なファイルが揃ったら、root になって、
``/'' ディレクトリで
gunzip < rpm-2.2.9-1.i386.cpio.gz | cpio -ivumd
次に RPM の使用するデータベースファイルの準備をしましょう。
まず、root のまま(CWD は何処でも構いません)、
RPM の使用するデータベースファイルを置くためのディレクトリを
作成しましょう。
mkdir /var/lib/rpm
そして、
rpm --initdb
/var/lib/rpm にデータベースファイルが作成されます。
これで RPM のインストールは完了しました。
RPM を用いて、.rpm バイナリパッケージのインストール
を行なう事が出来る筈です!
RPM に対する設定は、
/usr/lib/rpmrc,/etc/rpmrc, $HOME/.rpmrc/usr/lib/rpmrcRHS の勧める RPM の設定が記述されている
/etc/rpmrcサイト毎の設定ファイル
$HOME/.rpmrc各個人毎に設定を行なうためのファイル
/usr/lib/rpmrcは RPM パッケージに含まれて
いますが、/etc/rpmrc 及び $HOME/.rpmrc
は各自が作成する必要があります。
(RPM バージョン 2.2.7 以前は /etc/rpmrc も配付パッケージに
含まれて いたのですが、バージョン 2.2.8 以降は望ましい設定値が全て
/usr/lib/rpmrc に書かれるようになったため、
同梱されなくなりました。
/etc/rpmrc が無い!
節を参照して下さい。
また、バージョン 2.2.8 でのバグについては、
RPM をアップグレードした際にエラーが出る
節を参照して下さい。)
RPM は、ディフォルト(即ち、/usr/lib/rpmrcの設定)では、
パッケージ作成ツリーの最上位ディレクトリを
topdir: /usr/src/redhat
BUILDRPMSRPMS/{i386,axp,sparc}SOURCESSPECSSRPMSroot として作成するためには
不可欠ですので、対応するディレクトリツリーを作成しておいて
下さい。
夫々のディレクトリは
BUILDソースを展開し、パッチを当て、make を行なう
RPMS/{i386,axp,sparc}完成したバイナリパッケージ(*.rpm)が置かれる
(使用しているシステムが ix86 アーキテクチャなら、RPMS/i386
に置かれます。)
SOURCESソースファイル、パッチを置く
(``glint'' の使用するアイコン用の gif ファイル等もここに置きます。)
SPECSパッケージ作成用の仕様書(spec ファイル)を置く
SRPMS完成したソースパッケージ(*.src.rpm)が置かれる
この他にも、make して出来たファイルをその下に
「仮想的にインストール」してバイナリパッケージを作成する
ためのディレクトリ(``BuildRoot:'')も用いられます。
こちらは、作成する各パッケージ毎に設定できますので、
spec ファイルを書く際
に説明します。
以上のディレクトリツリーさえ有れば、root として
パッケージを作成する事が出来ます。
しかし、/usr/src 以下には(恐らく)書き込み権の無い
一般ユーザ「も」自分のホームディレクトリ以下にパッケージ作成
用ディレクトリツリーを設定し、RPM を用いてパッケージを作成する
事が出来ます。
パッケージ作成用ディレクトリツリーを一般ユーザの
ホームディレクトリ以下に設定するには、そのユーザの
$HOME/.rpmrc ファイル中に
topdir: /home/hogehoge/<mybuilddir>
<mybuilddir>以下に
BUILD, RPMS,... といったサブディレクトリを作成
しておけば良いのです。
ここでは、ユーザ hogehoge のパッケージ作成用
ディレクトリを、そのホームディレクトリの下の
<mybuilddir> に設定しています
(勿論、<mybuilddir> はあなたが使用する
実際の作成用ディレクトリに置き換えて下さい)。
以後、 /home/hogehoge/<mybuilddir> 等を
<topdir> と記述します。
まずは、オリジナルのソースを展開し、make 出来る様に
しましょう。
ここでは、ソースファイルが harehore-1.23.tar.gz
というファイルに保存されているとします。
<topdir>/SOURCES に harehore-1.23.tar.gz
を持って来ます。
<topdir>/BUILD で、オリジナルソースを展開します。
必要な(ソフト自体に対する)パッチも当てましょう。harehore-1.23'' という
ディレクトリを作成し、そのディレクトリに移って展開して下さい。)
harehore-1.23'' の名前を
``harehore-1.23.orig'' 等
に変更します。
harehore-1.23''
中にソースファイルを展開します。
harehore-1.23'' に移り、うまくmake 出来る
ようになるまで変更を加えます。
make 出来るようになったら、make clean
等の操作によりソース・ディレクトリ内の *.o 等を消去した後、
パッケージ作成の為のパッチを作成し、<topdir>/SOURCES
に置きます。<topdir>/BUILD で
diff -uNr harehore-1.23.orig harehore-1.23 > ../SOURCES/harehore-1.23.patch
RPM は、make して出来たバイナリその他を一度システム上に
インストールし、それらを用いてバイナリパッケージを作ります。
しかし、これでは、システム上に既にインストールされているファイルを
上書きしてしまう可能性があります。
これを避ける為に、あるディレクトリを指定し、それをインストールする
ディレクトリツリーの最上位ディレクトリに見立てて、そのディレクトリ
以下に「仮想的に」インストールし、バイナリパッケージを作成する
事ができます。
最上位ディレクトリの指定は、Imakefile 等を用いている
プログラムの場合は変数 DESTDIR で、また GNU
のソフトの場合は Makefile の中の PREFIX
(prefix) 等で指定する事が出来ます。
しかし、その様な機構が用意されていない場合は、インストールする
ディレクトリツリーの最上位ディレクトリを指定できるように、
Makefile 等を改造しておきましょう。
例えば、以下の様な仮想的な Makefile の一部
----------
BINDIR=/usr/local/bin
LIBDIR=/usr/local/lib/harehore
.......
install :
install -s harehore ${BINDIR}
.......
----------
----------
installprefix=$(ROOT)
BINDIR=$(installprefix)/usr/local/bin
LIBDIR=$(installprefix)/usr/local/lib/harehore
.......
install :
install -s harehore ${BINDIR}
.......
----------
この Makefile に施した変更も、patchにして
<topdir>/SOURCES に置いておきましょう。
(これらの変更を施してから前節の最後で述べた
diff
の操作を行なって patch を作るのでも構いません。)
次はいよいよ、.rpm 及び .src.rpm を作成する為の
「仕様書」である spec ファイルを作成します。
ただズラズラと spec ファイル中に記述すべき項目の説明を羅列
しても分かりにくいだけですので、例をあげて説明しましょう。
ここでは、著者の一人が作成した plain2-2.54 用の
spec ファイル、``plain2-2.54-3.spec''
を例に取って説明します。
注：通常、.rpm 等のファイル名は、
<パッケージ名>-<バージョン番号>-<リリース番号>.<アーキテクチャ>.rpm
とします。例えば、i386 向けに作成した
plain2 のバージョン 2.54
の 3 番目の rpm リリースに対しては、
plain2-2.54-3.i386.rpm
以下に上記のspecファイルを示します。
右端の数字は解説用のインデックスで、実際のspecファイル
には書かれていません。
---------- plain2-2.54-3.spec ----------
Summary: Plain2 plain text -> LaTeX/troff converter 1.
Name: plain2 2.
Version: 2.54 3.
Release: 3 4.
Group: Applications/Publishing/TeX 5.
Source: Flux.tokai.jaeri.go.jp:/plain2-2.54.tar.gz 6.
Copyright: 7.
Packager: Kazuyoshi Furutaka <furutaka@Flux.tokai.jaeri.go.jp> 8.
URL: http://Flux.tokai.jaeri.go.jp 9.
BuildRoot: /home/furutaka/work/rpm/plain2 10.
Patch: Flux.tokai.jaeri.go.jp:/plain2-2.54.patch 11.
%package docs 12.
Summary: Documents package of plain2 13.
Group: Applications/Publishing/TeX 14.
%description 15.
Plain2 plain text -> LaTeX/troff converter (desc.) 16.
%description docs 17.
This package contains lots of documentation and Makefile 18.
for plain2 plain text -> LaTeX/troff converter.
%prep 19.
%setup 20.
%patch -p1 21.
#%patch -p1 22.
rm -rf $RPM_BUILD_ROOT --
mkdir -p $RPM_BUILD_ROOT/usr/local/bin 23.
mkdir -p $RPM_BUILD_ROOT/usr/local/lib/plain2 --
%build --
cd src 24.
make --
%install --
cd src 25.
make installprefix="$RPM_BUILD_ROOT" install --
%clean --
rm -rf $RPM_BUILD_ROOT 26.
--
%post --
chown -R root.root /usr/local/lib/plain2 27.
chown root.root /usr/local/bin/plain2
chown -R root.root /usr/doc/plain2-2.54-2 --
%files --
%dir /usr/local/lib/plain2 ↑
/usr/local/bin/plain2
/usr/local/lib/plain2/OHP.p2
/usr/local/lib/plain2/OHP_t.p2 28.
/usr/local/lib/plain2/header.p2
/usr/local/lib/plain2/header_t.p2
/usr/local/lib/plain2/jbook.p2 ↓
/usr/local/lib/plain2/supsnum.p2 --
%files docs 29.
%doc doc/*
---------- end of plain2-2.54-2.spec ----------
では、各エントリーについて、順番に説明して行きます。
1.--18. はヘッダで、RPM を用いてパッケージの問い合わせ等に対する 返答や、ソースアーカイブなどの名前を記述しておくのに用いられます。
spec ファイル)の簡単な説明です。
-''
を用いる事は出来ません。
しようがないので、代わりにアンダースコア ``_''
を使って下さい。)
.rpm 及び .src.rpm)パッケージの
リリース番号です。Extensions/Japanese という階層が有ります。
(しかし、そこには ktermしか有りませんが(^^;;)
ftp
サイトを記述します。topdir: の下の SOURCES
ディレクトリにソースファイルが置いてあれば問題無い様です。)
rpm -qiしただけでは
情報が表示されません。)
URL を書いておきます。 rpm -qi では情報が表示
されません。)
Source:''(ソースの置き場所)と同様に、
この様な書式で指定し、かつ <topdir>/SOURCES
にパッチファイルが置かれていれば、問題無く動作するようです。)
12.--14. は、ソースに含まれるファイルの一部を別のパッケージとする
場合のエントリです。(すべてのファイルを単一パッケージとする
場合は必要ありません。)plain2-2.54-2.i386.rpm の他に
plain2-docs-2.54-2.i386.rpm
という文書ファイルのみを含んだパッケージが作成されます。
docs という別パッケージを作成する事を宣言します。plain2-2.54-2.i386.rpm)の説明文のタグです。
plain2-docs-2.54-2.i386.rpm)の説明文のタグです。
BUILD ディレクトリに展開し、パッチを当てる、
等の作業内容を記述しておくためのタグです。
cd する」ことです。
オプションには
-n <name>, -c, -b #, -a #, -T, -D
等があり、夫々、
-n <name>ソースを展開した後に cd するディレクトリ名を
<name> とします。
ディフォルトでは $NAME-$VERSION です。
他には、
例えば $NAME, ${NAME}${VERSION} 等と
する事も出来ます。
(RPM-HOWTO にはこう書いてありますが $NAME は
$RPM_PACKAGE_NAME と書かないとダメな様です。)
-cソースファイルを展開する「前に」、指定したディレクトリを作成し、
そこにcd します。
上の -n <name> オプションと組み合わせて
%setup -n <name> -c
<name> というディレクトリを作成し、
そこに cd する様にします。
-b #展開先ディレクトリにcdする「前に」
# 番目のソース(Source#:)を展開します。
-a #展開先ディレクトリに cd した「後で」
# 番目のソース(Source#:) を展開します。
-Tディフォルトでは、%setupが現れる「毎に」
``Source:''に示されたソースが展開されてしまいます。
そこで、複数のファイルが有る時は、二番目以降の%setup
ではこのオプションを指定して、再び``Source:''が
展開されない様にします。
これに先だつ%setupで-b 0 又は -a 0
と指定して、メインのソース「のみ」を展開しておかなくてはなりません。
-Dディフォルトでは、%setup「毎に」BUILD
ディレクトリに展開したものを消去してしまいます。
そこで、このオプションを指定して、二番目以降のソースを展開する
際に(既にBUILD に作成されている)ソースディレクトリを消去
しない様にします。
#ヘッダ中に Patch#: で示されている # 番目の
パッチを当てます。
-p #patch(1) コマンドに渡すべき、飛び越し可能
ディレクトリの階層数を # で指定します。
-Pディフォルトの動作
(Patch もしくは Patch0を当てる)
を抑止し、メインのソースがエラー無く展開できた事(返り値 0)を
確かめます。
%patch # -P とする代わりに %patch#
と指定する事も出来ます。
#'
にします。
RPM_BUILD_ROOT は、ヘッダ中で
``BuildRoot:'' により
指定したディレクトリに展開されます。
このように、%prep や
%buildといった
各タグの中では shell コマンドを書いておいて
実行させる事が出来ます。
%build は実際の make を行なう
過程を示すタグです。
%install は、インストール過程で行なう
作業を記述するタグです。
即ち、「BuildRoot: で指定されたディレクトリ
以下に仮想的にインストール」を行なっています。
root に変更しています。)
%files は、このパッケージが所有するファイルを
リストしておくためのタグです。
あるファイルがどのパッケージの所有物であるか問い
合わせる際や、パッケージを削除する際などに用いられます。
この際、各ファイルに
%dir, %doc %config
等の印をつけておく事も出来ます。
%dirこれを付けられたディレクトリ「のみ」がこのパッケージ所有の ものであることを示します。 これを付けずにディレクトリを指定すると、そのディレクトリ 「中のすべてのファイル」がそのパッケージに属すると見做され、 インストールされます。
%doc文書ファイルである事を示します。
ディフォルトでは
/usr/doc/$NAME-$VERSION-$RELEASE
にインストールされます。
%config設定ファイルである事を示します。 アップグレード時には、古いリリースパッケージ中でこの印を付けられた ファイルに変更が加えられていない場合はそのまま消去し、変更 されていた場合はファイル名に .rpmsave を付けて保存します。
docs) の所有するファイル
を示すための、別の %files タグです。
サブパッケージを作らない場合は
%doc doc/* の行を 27. に含めておけば良いだけです。
上で用いられている以外にも、以下のようなタグがあります。
%preインストール前に行なう動作を記述するタグ
%preunアンインストール前に行なう動作を記述するタグ
%postunアンインストール後に行なう動作を記述するタグ
%post には、
「一般ユーザとして作成したためファイルの所有者がそのユーザに
なってしまっている」ので chown したい場合や、
chmod したい場合などに用いる事が出来ます。
%setup セクションの
-n オプションを使うと、ソースを展開した
後で cd し、また %build
で作業をするディレクトリの名前を指定することができます。
kon のソース(kon-0.99.4g.tar.gz)
を例に取りましょう。このソースファイルを展開すると、
drwx--x--x manabe/dsl 0 Apr 17 16:06 1996 kon/
drwx--x--x manabe/dsl 0 Apr 17 00:53 1996 kon/font/
-rw------- manabe/dsl 4552 May 8 12:39 1994 kon/font/minix.c
-rw------- manabe/dsl 491 Apr 6 12:57 1996 kon/font/Makefile
(以下略)
kon というディレクトリの下にソースファイルが
展開されます。
一方、RPM は
${RPM_PACKAGE_NAME}-${RPM_PACKAGE_VERSION}
というディレクトリ以下にソースが展開されているものとして、
%setup マクロを実行した後はそのディレクトリに
cd しようとします。
この場合は、単に %setup とやるのではなく、
%setup -n kon
と指定すれば、上記ソースを展開した後 kon という
ディレクトリに cd します。
また、%buildの際もこのディレクトリで作業を
します。
特に、この場合は $RPM_PACKAGE_NAME = kon
ですので、
%setup -n $RPM_PACKAGE_NAME
因みに、RPM の中で定義されていて、spec ファイルの中で
使う事が出来る変数としては以下の様なものがあるようです。
(中身は筆者の一人の環境での例です。)
RPM_ARCH=i386
RPM_BUILD_DIR=/home/ishioka/local/work/package/redhat/BUILD
RPM_BUILD_ROOT=/home/ishioka/local/work/package/rpm-tmp
RPM_DOC_DIR=/usr/doc
RPM_OPT_FLAGS=-O2 -m486 -fno-strength-reduce
RPM_OS=Linux
RPM_PACKAGE_NAME=kon
RPM_PACKAGE_RELEASE=0
RPM_PACKAGE_VERSION=0.99.4g
RPM_ROOT_DIR=/home/ishioka/local/work/package/rpm-tmp
RPM_SOURCE_DIR=/home/ishioka/local/work/package/redhat/SOURCES
%setup -c を使うと、まずソースを
展開するディレクトリを作成し、そこに cd したあとで
ソースを展開してくれます。 例えば、xc32.tar.gz の場合、
ソースを展開すると次のようにカレントディレクトリにファイルを作る
ので...
tar tzvf ../SOURCES/xc32.tar.gz
-rw-rw-r-- 0/1 3343 Jun 14 07:53 1991 .autocis
-rw-rw-r-- 0/1 1152 Jun 6 10:56 1991 .uni
-rw-rw-r-- 0/1 824 Jun 6 10:56 1991 .callhq
-rw-rw-rw- 0/1 4127 Aug 25 10:17 1991 Makefile
この様な場合は、
%setup -c -n xc-3.2
xc-3.2 というディレクトリを作って
cdさせ、そこに展開させます。
あとは普通の場合とおなじです。
以下のように複数のソースを順に展開することができます.
Source: xc32.tar.gz .......... メインのソース
Source1: xc32pat.tar.gz ....... サブソース1
Source2: xc32news.tar.gz ...... サブソース2
%prep
%setup -c ..................... (1)
%setup -D -a 1 -T ............. (2)
%setup -D -a 2 -T ............. (3)
(1) では メインのソース(Source: で指定したもの) を
展開しています。
xc の場合、カレントディレクトリにファイルを作るので、
-c オプションで先にディレクトリを作成し、
cd した後で展開させています。
(2), (3)ではサブソースを展開していますが、これも(1) と同様の
理由から -c を付加しています。
また, それぞれ Source[12]: を指定
するために -a # オプションも使っています。
ここでは、-D オプションを使って、
(1)で展開したディレクトリを消去してしまわない様にしています。
こうしておかないと、せっかく展開したメインのソースが消されて
しまうのです！
また、単に -a 2 とだけ指定すると、
Source2 「と Source」 が展開
されてしまうので、-T オプションも指定しています。
%path マクロは、パッチファイルが圧縮されていても
動作するようです。
(自動的に ``gzip -dc <PatchFile> | patch ...''
を行なってくれる。)
また、%patchマクロのオプションとしては、
undocumented ではありますが、下記の様な patch(1)
オプションも指定する事が出来るようです。
-b xxxバックアップとして保存するファイルの拡張子を .orig
から .xxx に変更する。
-Rリバースパッチを施す。
-Eパッチを当てた結果空になったファイルを削除する。
specファイルを書いてしまえば、
あとは <topdir>/SPECS
に移って RPM を使ってパッケージを作成するだけです。
RPM 構築コマンドの一般的な形は
& rpm -bO [作成オプション] <specファイル名>+
[作成オプション]は man page の翻訳等を
参照して頂くことにして、ここでは -bO の部分だけを
説明します。
-bO は spec ファイル中で記述したどの過程
(タグ)まで作業を行なうかを指定するものです。
-bp%prep 過程まで、即ち、ソースを展開してパッチを
当てるところまで作業を行ないます。
-bl%files で記述されたファイルのリストの検査を
行ないます。
-bc%build 過程(通常は実行ファイルを make
するところ)まで行ないます。
-bi%install 過程(通常 make install を行なう)
までを行ないます。
-bb(%prep, %build, %install を行なって
から)バイナリパッケージを作成します。
-ba(%prep, %build, %install を行なって
から)バイナリ及びソースパッケージを作成します。
一つだけ [作成オプション] について説明しておきます。
--short-circuit をつけると、(-bc 又は
-bi とともに用いた場合は)
その前の過程をやらずにいきなり目的とする過程を実行します。
さて、-bb または -ba を指定してパッケージを
作成してみましたか？
うまく行けば、
<topdir>/RPMS/<arch>
にバイナリパッケージ(xxx.<arch>.rpm)が、<topdir>/SRPMS
にソースパッケージ(xxx.src.rpm)が
「でも、お前の作ったのなんて、大丈夫なの?...」
テストに関しては、RPM-HOWTO と重複が多くなるので、改めて 多くを述べる事は致しませんが...
究極のテストは、やはり全く異なるマシンにインストールして 使用してみる事です。
いくら(パッケージを作成した)自分のマシンにインストールして
テストしても、(例えrpm -eしたとしても、何度も
何度も make installしたマシンでは、設定ファイル
等が残っていたりして)完全にはテストすることが出来ません。
そ・こ・で...
親しい Linuxer に「こんなのを作ってみたんだけど、使ってみない?」 と(甘い言葉を囁いて)テストしてもらうのが良いのではないでしょうか? (当然の事ながら、複数の Linux box をお持ちの方は、 自分の別のマシンにインストールしてみれば良い訳ですが。)
しかし、まず友達に渡す前に、最低限
rpm -qp --scripts <PackageName>
%pre及び%postインストールスクリプト
でとてつもなく変な/愚かな事をやっていないか?位は確認しておかないと、
友達をなくしますよ!!!
これは非常にばかげた例ですが、先程例に上げた
plain2-2.54-3.spec
で作られるサブパッケージ
plain2-docs-2.54-3.i386.rpm に含まれる
ファイルは plain2 で加工してはじめて
TeX のファイルとなるため、
plain2-2.54-3.i386.rpm (plain2 本体)が
インストールされていなければなりません。
このような場合には、spec ファイル中に
Requires: plain2
plain2-docs-2.54-3.i386.rpm を
インストールするためには plain2 というパッケージが
インストールされていなくてはいけない」という依存性関係を明示
しておく事が出来ます。
もし plain2 がインストールされていないのに
plain2-docs をインストールしようとすると、
[root@Flux i386]# rpm -ivh plain2-docs-2.54-3.i386.rpm
failed dependencies:
plain2 is needed by plain2-docs-2.54-3
Requires: にメイン
パッケージを指定する事も出来ます。)
Requires: の指定にはバージョン番号を含める事も出来ます。
例えば:
Requires: perl >= 5.003
同時に複数のパッケージを Requires: に指定する事も出来ます:
Requires: perl >= 5.003, python
ところで、RPM 中のバージョン番号の新旧判断アルゴリズムは大抵の
場合うまく働きますが、β版である事を示すために b
が付けられている場合もあり、この時は例えば 5.003b は
5.003 よりも新しいと判断されてしまいます。
このような事態を回避するために、パッケージにシリアル番号を
付けておく事が出来ます。
Serial: 19
Requires: で指定
するには
Requires: perl =S 19
ここで、あるパッケージを使用するにはなんらかの
fortran コンパイラが必要であるが、コンパイラ自体は
fort77(をコンパイラと呼ぶなら) でも g77
でも良いという場合を想像してみましょう。
こういう場合には、個々のパッケージ (fort77 又は
g77) を指定する代わりに
「なんらかの fortran コンパイラ」として仮想的な
パッケージを Requires: に指定する事も出来ます:
Requires: fortran
fort77 又は g77 パッケージに
Provides: fortran
しかし、便利な依存性関係も、いちいち全て Requires:
で指定しなくてはならないとしたら、たまったもんではありません。
また、そのパッケージが依存するパッケージをいちいち手で調べて追加
していくのも容易ではありません。
そこで、RPM は、パッケージのファイルリスト中に共有ライブラリ
を必要とするものがあった場合は、(その so 名が)
Requires: に指定されているものと見做してそのパッケージ
の依存性リストに自動的に追加して行きます。
また、逆にそのパッケージが供給する共有ライブラリの
so 名も自動的に追加されます。
RPM で作成したパッケージが本当に query により表示
される人が作ったものかどうか、またパッケージが ftp
等の際に損傷していないかを調べられるように、
各パッケージには電子署名を付けておく事が出来ます。
現在は (version 2.2.9) MD5, SIZE, PGP の署名を
サポートしています。
MD5, SIZE の署名は常に行なわれます。
PGP 署名をする場合はオプション引数にて指定します。
(PGP の鍵束はディフォルトでは $HOME/.pgp に
置かれていると想定していますが、環境変数PGPPATH で、
もしくは $HOME/.rpmrc ファイル中に pgp_path:
という行を書いておく事によって変更する事が出来ます。)
パッケージの作成と同時に PGP 署名をするには、オプション
引数に --sign を付け足すだけです。
既存のパッケージに PGP 署名をし直す場合は、
rpm --resign <package>
しかし、この場合は以前付けられていた署名は消去されてしまい
ます。
新たに PGP 署名を追加したい場合は、
rpm --addsign <package>
(でも、あなたの公開鍵を公開しておかないと、 他の人は確かめようがありませんよ!!!)
JE 環境で rpm --help 等とすると
Segmentation Fault を起こして、RPM が死んでしまう
のですけれど...
rpm -ivh <package> 等は正常に働きます。
RPM は、多国語対応化するために
GNU gettext utility を使って
います。そして、環境変数 LANGUAGE, LC_CTYPE, LC_ALL, LANG
を順番に調べて行き、いずれかが設定されていた場合は、
対応する gettext の RPM.mo ファイルを
/usr/lib/locale/<lang>/LC_MESSAGES/ に読みに
行きます。
ところが、通常の日本語環境(JE)では、LANG=ja_JP.ujis に設定して
いるので、/usr/lib/locale/ja_JP.ujis/LC_MESSAGES/RPM.mo
を読みに行くと、そこに RPM.mo が無いために
Segmentation Faultしてしまう、という事になっているようです。
従って、``export LANG=''とやって、LANG を
空にしてみて RPM --help が正常に動作すれば、こういう
問題ですので、
export LANGUAGE=C
RPM.mo(筆者の一人が作成しました)
を
/usr/lib/locale/ja/LC_MESSAGES/
export LANGUAGE=ja
RPM をアップグレードしたら /etc/rpmrc が入ってないのですが。
恐らくバージョン 2.2.8 以降をお使いなのでしょう。
バージョン 2.2.8 以降は、望ましいディフォルト設定値が
/usr/lib/rpmrc 中に全て記述されているため、
/etc/rpmrc は配付されなくなりました。
勿論、自分で /etc/rpmrc を作成して設定を書いておく事は
有効です。
RPM をアップグレードする際にエラーが表示されるのですが。
バージョン 2.2.8 では、/usr/lib/rpmrc ファイル中に
typo があり、
bad option 'arch_cnaon' at /usr/lib/rpmrc:50
/usr/lib/rpmrc の上記 ``arch_cnaon'' となって
いる箇所を ``arch_canon'' に訂正して下さい。
この文書を書く上で、多くの方の方からの協力を頂きました。 ここに感謝の意を表したいと思います。
本文書に記述した大部分の事柄の情報源となっている RPM-HOWTO の翻訳の労を取られるとともに、 原稿を通してお読み下さった上で非常に有益な示唆・指摘を 頂きました。
原稿をお読み頂き、非常に有益な示唆・指摘を頂きました。
%patch マクロの隠れた機能に関する情報を
お寄せ頂きました。
本文書の元となる多くの貴重な情報及び経験をお寄せ下さいました。
たまたま第一筆者の近くで Slackware を使っていたが為に、 第一筆者の実験台とされ、 文句も言わずに(筆者が耳を貸さなかっただけ？) 数多くのテストを行なって下さいました。