Red Hat Training

A Red Hat training course is available for Red Hat Satellite

付録B カスタムパッケージの管理

本章では Red Hat Network 経由で正しく配信できるパッケージの構築方法の概要を記載しています。RPM を使用する理由、 Red Hat Network 用のパッケージの構築方法、およびパッケージの正しい署名法などについて説明します。

B.1. Red Hat Network のパッケージの構築

Red Hat Network は RPM パッケージマネージャ (RPM) の技術を使用して、各クライアントシステムに適用できる追加ソフトウェアや更新などを確認します。Red Hat Network から取り込まれるパッケージは通常 RPM 形式になりますが、ISO 全体のイメージは Red Hat Network Web サイトの ソフトウェア タブで入手可能です。ただし、Red Hat Satellite インストールの場合には利用できません。Satellite サーバーで Solaris のサポートを有効にしている場合は、Red Hat Network Push を使用して Solaris のクライアント群で使用されるカスタムチャンネルに Solaris のパッケージ群をアップロードしてください。
RPM はソフトウェアパッケージのインストール、 アンインストール、 アップグレードおよび検証などをユーザーが簡単に行うことができるツールです。また、ソフトウェア開発者なら、このツールを使用してプログラムのコンパイル版とそのソースコードをエンドユーザーおよび開発者向けにパッケージ化することもできます。

B.1.1. RPM の利点

RPM には次のような利点があります。
簡単なアップグレード
RPM を使用すると、新たに再インストールを行わなくてもシステムの個別コンポーネントをアップグレードすることができます。 Red Hat から Red Hat Enterprise Linux の新しいバージョンがリリースされる際には、ユーザーによるアップグレードのための再インストールは必要ありません。RPM によって完全に自動制御されているシステムアップグレードが用意されています。パッケージ内の設定ファイルはアップグレード後も保持されているためカスタムの設定が失われることはありません。パッケージのインストールおよびアップグレードには同じ RPM ファイルが使用されるため、パッケージの更新に特別なアップグレードファイルは必要ありません。
パッケージのクエリ
RPM はクエリのオプションを用意していますので、全パッケージまたは特定のファイルの検索を RPM データベース全体に対して行うことができます。また、任意のファイルの所属先またはパッケージの所属先を簡単に見つけることもできます。パッケージに含まれているファイルは圧縮されたアーカイブに入っています。そのカスタムバイナリヘッダーには役に立つパッケージの情報やその内容が含まれています。RPM によりヘッダーのクエリを素早くかつ簡単に行うことができます。
システムの検証
パッケージを検証する機能も備わっています。パッケージに関連したファイルが削除されている可能性を懸念している場合、パッケージの検証を行い、パッケージが提供するファイルの状態を確認することができます。この検証ではすべての異常が報告されます。エラーが存在する場合はそのファイルを簡単に再インストールすることができます。修正した設定ファイルは再インストール時にも維持されます。
純粋なソース
RPM の重要な設計目標のひとつは、オリジナルのソフトウェア著者により配布された通りの 純粋な ソフトウェアソースを使用できるようにすることです。RPM を使用すると、純粋なソースに使用されたパッチや構築方法に関する詳細な解説を付けてパッケージ化することができます。これは複数の理由で重要な利点となります。例えば、プログラムの新しいバージョンがリリースされた場合、コンパイルを完全に最初から始める必要はなく、パッチを見て何が 必要そうなのか を判定することができます。ソフトウェアを正常に構築できるようコンパイルされている全てのデフォルト設定や変更を、この技術を使用して簡単に確認することができます。
ソースを純粋に保持することは開発者以外の人にとっては重要には見えないかもしれませんが、純粋なソースの維持は高品質なソフトウェアにつながるためエンドユーザーにとっても重要なものとなります。

B.1.2. Red Hat Network RPM ガイドライン

RPM の長所は、正確に依存関係を定義し、競合を識別する能力にあります。Red Hat Network は RPM のこうした側面に依存しています。Red Hat Network は自動化した環境を提供することでパッケージインストール中に手動による介入が必要ないようにしています。そのため、Red Hat Network による配信用 RPM を構築する場合には次のルールに従うことが重要となります。
  1. RPM についてよく理解しておいてください。パッケージを正しく構築するには、RPM の重要な機能について基本的に理解しておくことが大切になります。RPM に関する詳細については次のリソースをまずご覧ください。
  2. 子チャンネル用に RPM を構築する場合は、子チャンネルのベースチャンネルと同じバージョンの Red Hat Enterprise Linux の新規インストール上でそのパッケージを構築します。最初に Red Hat Network からのすべての更新を適用することを忘れないようにしてください。
  3. RPM パッケージは --force または --nodeps のオプションを使用しないでインストールしてください。ビルドシステムで RPM を正常にインストールできない場合、Red Hat Network でもその RPM をシステムに自動的にインストールすることはできません。
  4. RPM パッケージのファイル名は NVR (名前、 バージョン、 リリース) 形式にしてください。また、パッケージのアーキテクチャも含ませる必要があります。name-version-release.arch.rpm が正しい形式となります。例えば、有効な RPM パッケージのファイル名が pkgname-0.84-1.i386.rpm とすると、パッケージ名は pkgname、バージョンは 0.84、リリースは 1、アーキテクチャは i386 になります。
  5. RPM パッケージはパッケージのメンテナーが署名する必要があります。署名のないパッケージも Red Hat Network で配信することができますが、そのパッケージを受信するには yum アップデーターに強制的に受理させる必要があります。このため、パッケージへの署名を強く推奨します。パッケージに署名する方法については 「Red Hat Network パッケージ用のデジタル署名」 に記載されています。
  6. 署名が変更されたり再コンパイルが行われたなど、パッケージが何らかの形で変更された場合にはそのバージョンまたはリリースを増分させる必要があります。つまり、Red Hat Network から配信する各 RPM の NVRA (アーキテクチャを含む) は、混乱を避けるため固有のビルドにそれぞれ対応していなければなりません。
  7. RPM パッケージがそれ自体を廃止予定にすることはできません。
  8. 一つのパッケージを複数のパッケージに分割させる場合は、 依存関係に充分に注意してください。 どうしても必要な理由がない限り、 既存のパッケージを分割するのは避けるようにしてください。
  9. インタラクティブなプレインストール、ポストインストール、プレアンインストール、またはポストアンインストールなどのスクリプトにパッケージを依存させることはできません。インストール中にユーザーによる直接介入を必要とする場合は Red Hat Network で動作させることはできません。
  10. プレインストール、ポストインストール、プレアンインストールおよびポストアンインストールなどのいずれのスクリプトにも stderr や stdout に書き込みを絶対行わせないようにしてください。メッセージが必要なければ /dev/null にリダイレクトさせてください。これ以外はファイルに書き込みを行なわせてください。
  11. spec ファイルを作成する場合は /usr/share/doc/rpm-<version>/GROUPS のグループ定義を使用します。完全に一致するものがない場合は 2 番目に適合するものを選択します。
  12. RPM の依存性機能を利用して、プログラムの実行が必ずインストールの後に行われるようにします。

重要

ファイルをアーカイブしてからポストインストールのスクリプトで解凍する手順で RPM は作成しないでください。RPM の利点が失われます。
アーカイブ内のファイルがファイル一覧に含まれていないと、競合に関する検証や確認を行うことができません。ほとんどの場合、RPM 自体がアーカイブを効率的に圧縮したり展開したりすることができます。 たとえば、 %postun セクションでクリーンアップを行わない %post の中にはファイルを作成しないでください。