インストール用ソフトウェアのパッケージ化

このトピックでは、installp コマンドを使用してインストールするアプリケーションの作成に関して説明します。

この節では、プロダクト開発者が提供する必要がある、 ソフトウェア・プロダクト・インストール・パッケージのフォーマットと内容について説明します。 ここでは、ソフトウェア・インストール・パッケージまたは更新パッケージの一部である必須ファイルおよびオプショナル・ファイルについて説明します。

ソフトウェア・プロダクト・インストール・パッケージは、ソフトウェア・プロダクトのファイル、必須のインストール制御ファイル、ならびにオプショナル・インストール・カスタマイズ・ファイルの入っているバックアップ・フォーマット・ファイルです。ソフトウェア・プロダクトをインストールし 更新するときは、installp コマンドを使用します。

インストール・パッケージ には、ファイルセット という、個別にインストール可能で、論理的にグループ化された、1 つまたは複数の単位が入っています。パッケージ内の各ファイルセットは、同じプロダクトに属していなければなりません。

ファイルセット更新 または更新パッケージ とは、既存のファイルセットへの変更を含むパッケージです。

このトピックにおいて、標準システム という用語は、ディスクレス・システムとして構成されていないシステムを指す場合に使用します。

インストール手順の要件

• インストールでは、ユーザー対話の必要があってはなりません。 ユーザーの対話が必要なプロダクトの構成は、インストール前後に行われている必要があります。
• 独立したファイルセットのインストールや、 相互依存のファイルセットの更新は、すべて単一インストール中に行うことができなければなりません。
• インストールでは、システムの再始動は必要ありません。 インストールでは、そのインストールに関連するシステムの部分を停止することがあり、インストールを完全に有効にするために、インストール後にシステムの再始動が必要です。

パッケージ制御情報の要件

パッケージ制御情報は、次のようになっていなければなりません。

• ファイルセットが他のファイルセットに対して持つすべてのインストール要件を指定している。
• ファイルセットのインストールのためのすべてのファイルシステムのサイズ要件を指定している。

ソフトウェア・パッケージのフォーマット

インストール・パッケージまたは更新パッケージは、インストール中に installp コマンドで復元できる、バックアップ・フォーマットの単一ファイルでなければなりません。 このファイルは、テープ、ディスケット、または CD-ROM で配布することができます。

パッケージ区分化の要件

ディスクレスまたはデータレスのクライアント・ワークステーションをサポートするために、パッケージのマシン固有の部分 (ルート部分) は、パッケージのマシン共有可能の部分 (ユーザー部分) と分けておく必要があります。 パッケージのユーザー部分には、 /usr または /opt ファイルシステムに常駐するファイルが入っています。

パッケージのルート部分のインストールでは、 /usr ファイルシステムのどのファイルも変更してはなりません。 /usr ファイルシステムは、 ディスクレスまたはデータレスのクライアント・システムのルート部分のインストールの間は、書き込みはできません。 マシン固有 (ルート) 部分には、/usr または /opt のいずれかのファイルシステムにないものがすべて入っていなければなりません。

ワークロード区画用のパッケージ化

一部のソフトウェア・プロダクトでは、ワークロード区画 (WPAR) 用にパッケージ化する際に特殊な考慮事項があります。ソフトウェア・プロダクトが WPAR に正常にデプロイされるためには、ルート部分の処理中に /usr ファイル・システムまたは /opt ファイル・システムへの書き込みが試みられないようにパッケージ化される必要があります。これは、WPAR によりこれらのファイル・システムが読み取り専用モードでマウントされるためです。同様に、プロダクトがインストールされたシステムごとに行う必要がある構成は、必ずパッケージのルート部分から行う必要があります。

ワークロード区画にインストールする意図のないファイルセットについては、パッケージの lpp_name ファイルに PRIVATE 属性を指定しておく必要があります。

WPAR にインストールするときに別の構成にする必要があるファイルセットの場合は、パッケージ化スクリプトで環境変数 INUWPAR を検査して、ファイルセットが WPAR 内にインストールされるかどうかを判別することができます。

別の構成で WPAR にインストールされるファイルセットの場合、WPAR をシステム・コピーから作成するときに再構成されます。それは、そのファイルセットが元々 WPAR にインストールされていなかったためです。ファイルセット所有者は /usr/lib/wpars/wparconvert.d/usr ディレクトリーおよび /usr/lib/wpars/wparconvert.d/root ディレクトリーにプログラムを作成して、所有するファイルセット (システム・コピー WPAR 内で実行されるべきファイルセット) から usr およびルート部分を変換するときにそれらのプログラムを実行できます。これらのディレクトリー内の実行可能ファイルは、システム・コピー WPAR の最初の始動時に、すべてアルファベット順 (C ロケール) に実行されます。

ソフトウェア重要プロダクト・データ

ソフトウェア・プロダクトおよびそのインストール可能オプションに関する情報は、 ソフトウェア重要プロダクト・データ (SWVPD) データベースで維持管理されています。 SWVPD は、ソフトウェア・プロダクト情報を維持管理するためのコマンドの集合と、 オブジェクト・データ・マネージャー (ODM) のオブジェクト・クラスで構成されています。 ユーザーがインストール済みソフトウェア・プロダクトを照会 (lslpp) および検証 (lppchk) を行うための SWVPD コマンドが用意されています。 ODM オブジェクト・クラスは、維持管理されているソフトウェア・プロダクト情報の 配信範囲とフォーマットを定義します。

installp コマンドは、オブジェクト・データ・マネージャーを 使用して、SWVPD データベース内の以下の情報を維持管理します。

• ソフトウェア・プロダクトの名前 (bos.adt など)
• ソフトウェア・プロダクトのバージョン
• ソフトウェア・プロダクトのリリース・レベル。 これは、そのソフトウェア・プロダクトの外部プログラミング・インターフェースに対する変更を示します。
• ソフトウェア・プロダクトのモディフィケーション・レベル。 これは、そのソフトウェア・プロダクトの外部インターフェースには影響を及ぼさない変更を示します。
• ソフトウェア・プロダクトのフィックス・レベル。 これは、後で正規のモディフィケーション・レベルに組み込まれる予定の小さな更新を示します。
• ソフトウェア製品またはオプションを構成するファイルの名前、チェックサム、およびサイズ
• ソフトウェア・プロダクトの状態。 使用可能、適用中、適用済み、コミット中、コミット済み、リジェクト中、損傷のいずれか
• テクノロジー・レベルと APAR の情報
• installp 以外でパッケージ化されたソフトウェアの、宛先ディレクトリーとインストーラー (該当する場合)。

ソフトウェア・プロダクト・パッケージの部分

パッケージ区分化に関するサンプル・ファイル・システム・ガイド

以下に、ファイルシステムとディレクトリーの簡潔な説明を示します。 この説明は、プロダクト・パッケージをルート部分、ユーザー部分、および共有部分に分割するためのガイドとして使用できます。

いくつかのルート部分ディレクトリーとその内容を以下に示します。

/dev

ローカル・マシン・デバイス・ファイル

/etc

hosts および passwd などのマシン構成ファイル

/sbin

システムのブートに必要なシステム・ユーティリティー

/var

システムに固有のデータ・ファイルおよびログ・ファイル

いくつかのユーザー部分ディレクトリーとその内容には、以下のものがあります。

/usr/bin

コマンドとスクリプト (通常の実行可能プログラム)

/usr/sbin

システム管理コマンド

/usr/include

インクルード・ファイル

/usr/lib

ライブラリー、非ユーザー・コマンド、およびアーキテクチャー依存データ

/opt

通常はオペレーティング・システム・プロダクト以外に関連するライブラリー、非ユーザー・コマンド、およびスクリプト

パッケージおよびファイルセットの命名規則

デバイス・ドライバー・パッケージ化の特殊な命名に関する考慮事項

devices.BusTypeID.CardID.Extension

例えば、1410bb02 の固有のカード ID があるときに、イーサネット・デバイスを PCI バスに接続し、構成マネージャーが識別するとします。このイーサネット・デバイスに関連するファイルセットのパッケージの名前 は devices.pci.1410bb02 です。 このパッケージ内にあるランタイム環境のファイルセット の名前は、devices.pci.1410bb02.rte です。

メッセージ・カタログ・パッケージ化の特殊な命名に関する考慮事項

Product.msg.Language.SubProduct

プロダクトが同じ言語に対して複数のメッセージ・カタログ・ファイルセットを持っていて、それぞれのメッセージ・カタログ・ファイルセットが、異なる SubProduct に適用される場合は、オプションの .SubProduct 接尾部が使用されます。プロダクト全体に 1 つのメッセージ・ファイルセットを持たせるようにすることもできます。

例えば、Super_Widget プロダクトには、plastic セットおよび metal セットのファイルセット・オプションがあります。 Super_Widget 米国英語メッセージ・カタログは、すべて Super_Widget.msg.en_US という単一のファイルセットにまとめることができます。 plastic オプションと metal オプションに別個のメッセージ・カタログ・ファイルセットが必要な場合は、その米国英語メッセージ・カタログ・ファイルセットに、Super_Widget.msg.en_US.plastic と Super_Widget.msg.en_US.metal の名前が付けられます。

ファイル名

ソフトウェア・パッケージと一緒に引き渡されるファイルの名前には、 コンマもコロンも付けることはできません。 コンマおよびコロンは、ソフトウェア・インストール処理の際に 使用する制御ファイルで、区切り文字として使用されます。 ファイル名には、非 ASCII 文字を使用することができます。 ファイル名の絶対パスは、128 文字を超えてはなりません。

ファイルセット改訂レベルの識別

Version.Release.Modification.FixLevel

基本ファイルセット・インストール・レベル は、ファイルセットの初期インストールの全レベルです。 このレベルには、ファイルセット更新 (フル・ファイルセットからのファイルのサブセットが含まれる) とは対照的に、ファイルセット内のすべてのファイルが含まれます。

ソフトウェア・パッケージ内のファイルセットのファイルセット・レベルは、すべて同じでなければなりませんが、AIX® 4.1 フォーマットのパッケージの場合にはこれは必要ありません。

ファイルセットのレベルがすべて新しい場合は、 ファイルセット・レベルを増加させてください。 installp コマンドは、ファイルセット・レベルを用いて、 後続のインストールで、プロダクトが新しいレベルかどうかを検査します。

ファイルセット・レベル優先度は左から右に読みます (例えば、5.2.0.0 は 4.3.0.0 より新しいレベルです)。

ソフトウェア・パッケージの内容

この節では、インストール・パッケージまたは更新パッケージに 入っているファイルについて説明します。 ファイル・パス名は、インストール・パッケージ・タイプに対して付けられます。 更新パッケージに関しては、 PackageName がパス名の一部である場合は、必ず PackageName/FilesetName/FilesetLevel に置換されます。

ソフトウェア・パッケージの内容の例

/usr/bin/raisehog (パッケージのユーザー部分)
/usr/sbin/sellhog
 (パッケージのユーザー部分)

/etc/hog
 (in the root part of the package)

./lpp_name
./usr/lpp/farm.apps/liblpp.a
./usr/lpp/farm.apps/inst_root/liblpp.a
./usr/bin/raisehog
./usr/sbin/sellhog
./usr/lpp/farm.apps/inst_root/etc/hog

/usr/sbin/sellhog
/etc/hog

./lpp_name
./usr/lpp/farm.apps/farm.apps.hog/4.1.0.3/liblpp.a
./usr/lpp/farm.apps/farm.apps.hog/4.1.0.3/inst_root/liblpp.a
./usr/sbin/sellhog
./usr/lpp/farm.apps/farm.apps.hog/4.1.0.3/inst_root/etc/hog

lpp_name パッケージ情報ファイル

各ソフトウェア・パッケージには、lpp_name パッケージ情報ファイルが含まれている必要があります。 lpp_name ファイルは、installp コマンドに、 パッケージ、およびパッケージ内の各ファイルセットに関する情報を提供します。 ファイルセット更新パッケージの場合の「lpp_name ファイルの例」の図を参照してください。 図の中の数字と矢印は、後述の表で説明するフィールドを指しています。

1 23    4
| ||    |                6         7 8 9  10       11
4 RSfarm.apps {  |       |         | | |   |        |
 5--> farm.apps.hog04.01.0000.0003 1 N U en_US Hog Utilities 
12--># ...      
[
13--> *ifreq bos.farming.rte (4.2.0.0) 4.2.0.15
%
14--> /usr/sbin 48
14--> /usr/lpp/farm.apps/farm.apps.hog/4.1.0.3 280
14--> /usr/lpp/farm.apps/farm.apps.hog/inst_root/4.1.0.3.96
14--> /usr/lpp/SAVESPACE 48
14--> /lpp/SAVESPACE 32
14--> /usr/lpp/bos.hos/farm.apps.hog/inst_root/4.1.0.3/ etc 32
%
%
15--> ranch.hog 4.1.0.0
%
16--> IX51366 Hogs producing eggs.
16--> IX81360 Piglets have too many ears.
]
}

条件情報セクション

条件情報セクションには、他のファイルセットまたはファイルセット更新に対する インストールの依存関係に関する情報が入っています。 ファイルセットまたはファイルセット更新を適用するためには、必要条件セクションにリストされた各必要条件が、必要条件の規則に従って満たされなければなりません。

インストールまたは更新が行われる前に、installp コマンドは、インストールされるファイルセットの現在の状態を、lpp_name ファイルにリストされた要件と比較します。 -g フラグが installp コマンドに指定された場合は、インストールされるファイルセットのリストに、欠落している必要要件がすべて追加されます。 ファイルセットは、なんらかの前提条件に従って、 インストールのために並べられます。 ファイルセットがインストールされる直前に、installp コマンドは、そのファイルセットの必要条件を再度検査します。 この検査は、インストール・プロセスの前段階でインストール済みのすべての必要条件が正常にインストールされたこと、および必要条件のすべてが満たされていることを確認します。

さまざまなタイプの条件に関する以下の説明におい て、RequiredFilesetLevel は、 条件を満たす最低のファイルセット・レベルを表しています。 置き換え情報セクションで説明する理由により明示的にブロックされる場合を除き、ファイルセットの新しいレベルは以前のレベルの必要条件を満たします。 例えば、plum.tree 2.2.0.0 ファイルセットの条件は、plum.tree 3.1.0.0 ファイルセットによって満たされます。

前提条件

現行ファイルセットを正常にインストールするには、指定したファイルセットを、 指定のファイルセット・レベル以上のレベルでインストールしなければならないことが前提条件によって示されます。 前提条件ファイルセットをインストールするスケジュールをたてると、 installp コマンドはインストールするファイルセットのリストに順序をつけて、 前提条件が必ず満たされるようにします。 同じパッケージ内のファイルセットに対する前提条件は保証されません。

*prereq Fileset RequiredFilesetLevel

Fileset RequiredFilesetLevel

ファイルセット更新には、 その基本レベルのファイルセットに対する暗黙的前提条件が入っています。 この暗黙前提条件が十分でない場合は、別の前提条件を明示的に指定する必要があります。 更新のバージョン およびリリース と暗黙的前提条件は、同じです。 更新の FixLevel が 0 の場合、暗黙的前提条件の ModificationLevel と FixLevel は両方とも 0 です。それ以外の場合、暗黙的前提条件の ModificationLevel は更新の ModificationLevel と同じであり、FixLevel は 0 です。例えば、4.1.3.2 レベルの更新では、更新をインストールする前に 4.1.3.0 レベルをインストールする必要があります。4.1.3.0 レベル更新では、更新インストールの前に、その 4.1.0.0 レベルがインストールされている必要があります。

相互条件

相互条件は、現行ファイルセットが正常に機能するためには、 指定されたファイルセットがインストールされていなければならないことを示します。 インストール処理の終了時点で満たされていない相互条件があると、 installp コマンドから警告メッセージが出されます。 同じパッケージ内のファイルセット間の必要条件を示すのに相互前提条件を使用することもできます。

*coreq Fileset RequiredFilesetLevel

If 条件

*ifreq plum.tree (1.1.0.0) 1.1.2.3

*ifreq Fileset [(InstalledFilesetLevel)] RequiredFilesetLevel

plum.tree ファイルセットがまだインストールされていない場合、 この例ではそのファイルセットはインストールされません。 plum.tree ファイルセットが以下のレベルのいずれかで既にインストールされている場合は、この例では 1.1.2.3 レベルはインストールされません。

1.1.2.3

このレベルは RequiredFilesetLevel に一致する。

1.2.0.0

このレベルは、異なる基本ファイルセット・レベルである。

1.1.3.0

このレベルは、RequiredFilesetLevel を置き換える。

plum.tree ファイルセットが、既に以下のレベルのいずれかでインストールされている場合は、この例で 1.1.2.3 レベルがインストールされます。

1.1.0.0

このレベルは InstalledFilesetLevel に一致する。

1.1.2.0

このレベルは、InstalledFilesetLevel と同じ基本レベルであり、RequiredFilesetLevel のレベルより低い。

(InstalledFilesetLevel) パラメーターはオプショナルです。 これが省略されると、InstalledFilesetLevel と RequiredFilesetLevel の バージョン と リリース は同じと見なされます。 RequiredFilesetLevel の FixLevel が 0 の場合、InstalledFilesetLevel の ModificationLevel と FixLevel は両方とも 0 です。 そうでない場合、InstalledFilesetLevel は RequiredFilesetLevel の ModificationLevel と同じ ModificationLevel を持ち、FixLevel は 0 になります。 例えば、RequiredFilesetLevel が 4.1.1.1 で、InstalledFilesetLevel パラメーターが指定されていない場合、InstalledFilesetLevel は 4.1.1.0 になります。RequiredFilesetLevel が 4.1.1.0 で、InstalledFilesetLevel パラメーターが指定されていない場合、InstalledFilesetLevel は 4.1.0.0 になります。

インストール済み条件

インストール済み条件は、対応するファイルセットが 既に自動的にインストール済みであるか、またはインストールするファイルセットの リスト上にある場合に限り、指定されたファイルセットが自動的に インストールされる必要があることを示します。 インストール済み条件は、ユーザーが、 インストールされることを明示的に要求した場合もインストールされます。 ファイルセット更新に、インストール済み条件を付けることはできません。 特定パッケージのメッセージ・ファイルを含むファイルセットは、インストール対象のパッケージ内の他の部分なしでは自動的にインストールされないため、メッセージ・ファイルセットには常に、そのプロダクト内の他のファイルセットのインストール済み必要条件が含まれている必要があります。

*instreq Fileset RequiredFilesetLevel

グループ条件

グループ条件は、さまざまな条件がグループ条件を満たせることを示します。 前提条件、相互要件、IF 条件、 およびネストされたグループ条件をグループ条件内に入れることができます。 {RequisiteExpressionList } の前の Number は、RequisiteExpressionList 内に必要な項目数を識別します。 例えば、>2 は、 RequisiteExpressionList 内 に少なくとも 3 項目が必要であることを示します。

>Number { RequisiteExpressionList }

条件情報セクションの例

1. 次の例は、相互要件の使い方を説明しています。 book.create 12.30.0.0 ファイルセット は、layout.text 1.1.0.0 および index.generate 2.3.0.0 ファイルセット のインストールなしには、機能することはできないため、book.create 12.30.0.0 の必要条件セクションには、 次のものが入っています。

   *coreq layout.text 1.1.0.0
   *coreq index.generate 2.3.0.0

   3.1.0.0 のレベルは、必要とされる 2.3.0.0 レベルより新しいので、index.generate 3.1.0.0 ファイルセットは、index.generate 条件を満たします。
2. 次の例は、さらに一般的な条件タイプの使い方を説明しています。 ファイルセット new.fileset.rte 1.1.0.0 には、次の条件が入っています。

   *prereq database.rte 1.2.0.0
   *coreq spreadsheet.rte 1.3.1.0
   *ifreq wordprocessorA.rte (4.1.0.0) 4.1.1.1
   *ifreq wordprocessorB.rte 4.1.1.1

   new.fileset.rte ファイルセットをインストールするには、 1.2.0.0 以上のレベルの database.rte ファイルセットをインストールしておく必要があります。 database.rte および new.fileset.rte を同じセッション・セッションでインストールする場合、 インストール・プログラムは new.fileset.rte ファイルセットより前に database ファイルセットをインストールします。

   new.fileset.rte ファイルセットが正しく機能するには、1.3.1.0 以上のレベルの spreadsheet.rte ファイルセットをインストールしておかなければなりません。 両方が同じインストール・セッションでインストールされるのであれば、new.fileset.rte ファイルセットのインストールより前に spreadsheet.rte ファイルセットをインストールしておく必要はありません。 インストール・セッションの終わりまでに、適切なレベルの spreadsheet.rte ファイルセットがインストールされないと、相互条件が満たされていない旨の警告メッセージが出されます。

   wordprocessorA.rte ファイルセットが 4.1.0.0 のレベルでインストールされる (または new.fileset.rte とともにインストールされている) 場合、wordprocessorA.rte ファイルセット更新は 4.1.1.1 以上のレベルでインストールする必要があります。

   wordprocessorB.rte ファイルセットが 4.1.1.0 のレベルでインストールされる (または new.fileset.rte とともにインストールされている) 場合、wordprocessorB.rte ファイルセット更新は 4.1.1.1 以上のレベルでインストールする必要があります。

3. 次の例は、インストール済み条件を説明しています。 2.1.0.0 のレベルの ファイルセット Super.msg.fr_FR.Widget には、 次のインストール必要条件が入っています。

   *instreq Super.Widget 2.1.0.0

   Super.Widget ファイルセットがインストールされていないと、Super.msg.fr_FR.Widget ファイルセットを自動インストールできません。 Super.Widget ファイルセットがインストールされていなくても、 インストール対象のファイルセットのリスト中に Super.msg.fr_FR.Widget ファイルセットが明示されていれば、このファイルセットをインストールすることができます。

4. 次の例は、グループ条件を説明しています。 リストされた前提条件ファイルセットのうち、 少なくとも 1 つはインストールされている必要があります (両方をインストールすることがで きます)。 spreadsheet_1.rte ファイルセットをインストールする場合、 1.2.0.0 以上のレベルでなければならず、spreadsheet_2.rte ファイルセットは 1.3.0.0 以上のレベルでなければなりません。

   >0 {
   *prereq spreadsheet_1.rte 1.2.0.0
   *prereq spreadsheet_2.rte 1.3.0.0
   }

サイズ情報およびご使用条件情報

サイズ情報およびご使用条件情報セクションには、ファイルセットのディスク・スペースとご使用条件の要件が含まれています。

サイズ情報

Directory PermanentSpace [TemporarySpace]

さらには、プロダクト開発者は、絶対パス名フィールドで PAGESPACE または INSTWORK を指定して、インストール処理の間に パッケージ・ディレクトリーで必要になるページング・スペースおよびワークスペースに関する ディスク・スペース要件を示すことができます。

Directory

サイズ要件を持つディレクトリーの絶対パス名。

PermanentSpace

インストールもしくは更新に必要な永続スペースのサイズ (512 バイト・ブロック単位)。 永続スペースとは、インストールの完了後に必要なスペースのことです。 このフィールドは、以下の場合はそれぞれ異なる意味を持ちます。

Directory が PAGESPACE ならば、PermanentSpace は インストールを行う際に必要なページ・スペースのサイズ (512 バイト・ブロック単位) を表します。

Directory が INSTWORK ならば、PermanentSpace は、 インストールの際に用いる制御ファイルの抽出に 必要な 512 バイト・ブロックの数を表します。 これらの制御ファイルは、liblpp.a ファイル にアーカイブされているファイルです。

TemporarySpace

インストールのみに必要な一時スペースのサイズ (512 バイト・ブロック単位)。 一時スペースは、インストールが完了すると解放されます。 TemporarySpace 値はオプショナルです。 一時スペースの例としては、実行可能オブジェクト・ファイルの再リンクに必要なスペースがあります。 もう 1 つの例としては、オブジェクト・ファイルをライブラリー にアーカイブする際に必要なスペースがあります。 ライブラリーに保管する場合、installp コマンドは、 ライブラリーのコピーをとり、オブジェクト・ファイルを、コピーされたライブラリーに アーカイブし、そしてコピーされたライブラリーを元のライブラリーに移動します。 ライブラリーのコピーのスペースは一時スペースと見なされます。

Directory が INSTWORK ならば、 TemporarySpace は、 抽出されない liblpp.a ファイルに 必要な 512 バイト・ブロックの数を表します。

/usr/bin          30
/lib              40  20
PAGESPACE         10
INSTWORK          10    6

ディスク・ファイルシステムがファイル・ツリーに どのようにマウントされるかを予想するのは困難であるので、 サイズ情報セクションのディレクトリー・パス名エントリーは、可能なかぎり具体的でなければなりません。 例えば、/usr/bin と /usr/lib は、両方とも /usr のもとにマウントされる異なるファイルシステム上に存在できるので、/usr 用に結合エントリーを持つよりも、/usr/bin 用のエントリーを 1 つ、 /usr/lib 用のエントリーを 1 つ持つ方が良策です。 一般に、ファイルのインストール先ディレクトリーごとにエントリーを組み込むのが最も良い方法です。

更新パッケージの場合に限って、save ディレクトリーに移動する古いファイル (置換されるもの) を、サイズ情報に入れる必要があります。 これらの古いファイルは、後で更新がリジェクトされると復元されます。 これらのサイズ要件を示すために、更新パッケージは以下の特殊ディレクトリーを指定する必要があります。

/usr/lpp/SAVESPACE

ユーザー部分ファイル用の save ディレクトリー。 デフォルトでは、ユーザー部分ファイルは /usr/lpp/PackageName/FilesetName/FilesetLevel.save ディレクトリーに保存されます。

/lpp/SAVESPACE

ルート部分ファイル用の save ディレクトリー。 デフォルトでは、ルート部分ファイルは /lpp/PackageName/FilesetName/FilesetLevel.save ディレクトリーに保存されます。

ご使用条件情報

新たに AIX インストール・プロセスに追加された機能により、プロダクトをインストールする前にご使用条件に署名 するように、お客様に対してプロダクトの所有者から要求できるようになりました。 installp コマンドは、どのイメージでも通常どおりにファイルセットの lpp_name ファイルを読み取ります。 lpp_name ファイルのサイズ・セクション内に LAF エントリーまたは LAR エントリーがあると、installp コマンドは inulag コマンドを呼び出し、ライセンスをウィンドウに表示してお客様によるライセンスの同意を記録します。 お客様がライセンスの同意を拒否した場合、 その製品のインストールは停止します。

ライセンス・ファイルの配置場所

ライセンス・ファイルの配置場所は製品の所有者に委ねられます。 ただし、ライセンスを /usr/swlag/LANG に置くことを強くお勧めします。 また、ご使用条件ファイルには、ProductName_VersionRelease.la という名前をつけることをお勧めします。 この名前や場所の使用に関する要件はありません。 installp コマンドとこのパッケージ化は、単に顧客に通知を送付する手段でしかありません。 ツールとファイル内容はすべて、プロダクトごとに提供する必要があります。

ライセンス・ファイルに対する翻訳要件

サポートされている言語にご使用条件ファイルを翻訳する必要がある場合、 このファイルを言語別に別々のファイルに振り分けることをお勧めします。 そのような翻訳のためにいくつかのファイルを作成する必要が生じることがあります。

ライセンス・ファイルの配布方法

製品所有者は、メイン製品の一環としてか、または製品用の別個のファイルセットに入れて、 ライセンス・ファイルを配布することができます。 たいていの製品では、ライセンス・ファイルの配布のためだけの別個のファイルセットが作成されています。 このようにすれば、いくつものフィーチャー内にそれぞれライセンス・ファイルを組み込まなくても、 多種多様なフィーチャーを備えた製品に対してライセンス・ファイルとファイルセットを 1 つ作成して、 各フィーチャーごとに必要なすべてのメディアに収めて配布することができます。 ファイルセット名として現在推奨されている名前は lpp.license または lpp.loc.license です。 現在、たいていの製品で、最初の推奨名が使われています。 標準インストールでは顧客からライセンス・ファイルセットを見えないようにしたい場合、 lpp.loc.license を使用します。なぜなら、 この種のインストールではライセンス・ファイルセットを選択する必要はないからです。

ライセンス・ファイルのパッケージ化の方法

LAF ファイルセットの例

iced.tea.loc.license 03.01.0000.0000 1 N U en_US IcedTea Recipe License Information
[
%
INSTWORK 16 160
LAF/usr/swlag/de_DE/iced.tea.la 24
LAF/usr/swlag/DE_DE/iced.tea.la 24
LAF/usr/swlag/en_US/iced.tea.la 24
LAF/usr/swlag/EN_US/iced.tea.la 24
LAF/usr/swlag/es_ES/iced.tea.la 24
LAF/usr/swlag/ES_ES/iced.tea.la 24
LAF/usr/swlag/fr_FR/iced.tea.la 24
LAF/usr/swlag/FR_FR/iced.tea.la 24
LAF/usr/swlag/it_IT/iced.tea.la 24
LAF/usr/swlag/IT_IT/iced.tea.la 24
LAF/usr/swlag/ja_JP/iced.tea.la 24
LAF/usr/swlag/JA_JP/iced.tea.la 32
LAF/usr/swlag/Ja_JP/iced.tea.la 24
LAF/usr/swlag/ko_KR/iced.tea.la 24
LAF/usr/swlag/KO_KR/iced.tea.la 24
LAF/usr/swlag/pt_BR/iced.tea.la 24
LAF/usr/swlag/PT_BR/iced.tea.la 24
LAF/usr/swlag/ru_RU/iced.tea.la 24
LAF/usr/swlag/RU_RU/iced.tea.la 48
LAF/usr/swlag/zh_CN/iced.tea.la 16
LAF/usr/swlag/zh_TW/iced.tea.la 16
LAF/usr/swlag/Zh_TW/iced.tea.la 16
LAF/usr/swlag/ZH_TW/iced.tea.la 24
%
%
%
]

LAR ファイルセットの例

iced.tea.server 03.01.0000.0010 1 N B en_US Iced Tea Recipe Group
[
*prereq bos.net.tcp.client 5.1.0.10
*coreq iced.tea.tools 5.1.0.10
*coreq Java14.sdk 1.4.0.1
%
/usr/bin 624
/usr/lib/objrepos 24
/usr/include 16
/usr/include/sys 56
/usr/lpp/iced.tea 22
/usr/samples/iced.tea 8
/usr/samples/iced.tea/server 504
/usr/lpp/iced.tea/inst_root/etc/tea 8
/usr/iced.tea 8
/usr/lpp/iced.tea/inst_root/etc/tea/Top 8
INSTWORK 208 96
/lpp/iced.tea 104
/etc/tea 8
/etc/objrepos 8
/etc/tea/Top 8
/tmp 0 6
LAR/usr/swlag/%L/iced.tea.la 0
%
%
%
]

置き換え情報セクション

置き換え情報セクションは、このファイルセットまたは ファイルセット更新が置き換えられるものとして使用される 可能性がある (ない場合もある)、 ファイルセットまたはファイルセット更新のレベルを示します。 置き換え情報はオプションであり、適用できるのは、AIX 4.1 フォーマットのファイルセット基本インストール・パッケージと AIX 3.2 フォーマットのファイルセット更新パッケージのみです。

新しいファイルセットは、lpp_name ファイルの 置き換えセクションが、置き換えるファイルセットの最新のレベルを識別しない限り、 そのファイルセットの古いバージョンをすべて置き換えます。 ファイルセットがそのファイルセットの前のレベルをすべて置き換えるとは限らないというまれなケースで は、installp コマンドは、置き換えセクションにリストされているファイルセットのレベルより古いレベルの条件を満たすために、 そのファイルセットを使用することはありません。

ファイルセット更新がそのファイルセットの古い更新を置き換えるのは、 そこに、古いファイルセット更新に入っていた、ファイル、構成処理、および 条件情報のすべてが入っている場合に限られます。 installp コマンドは、以下の条件で、ファイルセット更新が そのファイルセットの別の更新を置き換えることを決定します。

• 更新のバージョン、リリース、およびモディフィケーション・レベルが等しく、 フィックス・レベルがともにゼロ以外であり、かつフィックス・レベルがより高い更新に、 より低いフィックス・レベルを持つ更新のレベルより大きいかそれと等しい、ファイルセットのレベルに対する前提条件が入っていない。
• 更新のバージョン・レベルおよびリリース・レベルが等しく、かつモディフィケーション・レベルがより高い更新に、モディフィケーション・レベルがより低い更新のレベル以上であるファイルセットのレベルに対する前提条件が入っていない。

例えば、ファイルセット更新 farm.apps.hog 4.1.0.1 は、/usr/sbin/sellhog の更新を引き渡します。 ファイルセット更新 farm.apps.hog 4.1.0.3 は、 更新を /usr/sbin/sellhog ファイル および /etc/hog ファイルに引き渡します。 ファイルセット更新 farm.apps.hog 4.1.1.2 は、 更新を /usr/bin/raisehog ファイルに引き渡します。

更新 farm.apps.hog 4.1.0.3 は、同じファイルを引き渡し、同じレベルの farm.apps.hog 4.1.0.0 に適用するので、farm.apps.hog 4.1.0.1 を置き換えます。

更新 farm.apps.hog 4.1.1.2 には、同じファイルが入っておらず、かつ異なるレベル farm.apps.hog 4.1.1.0 に適用されるため、farm.apps.hog 4.1.0.3 も farm.apps.hog 4.1.0.1 も置き換えません。 更新 farm.apps.hog 4.1.1.0 は farm.apps.hog 4.1.0.1 および farm.apps.hog 4.1.0.3 を置き換えます。

ファイルセット・インストール・レベルの置き換えセクション (基本レベル)

AIX 4.1 フォーマットのファイルセット・インストール・パッケージには、以下の置き換えエントリーを入れることができます。

Barrier Entry

主な非互換性が取り込まれたファイルセット・レベルを識別します。 このような非互換性のために、現行ファイルセットは、 指定されたレベルより前のファイルセットのレベルの条件を満たせなくなります。

Compatibility Entry

該当のファイルセットを使用して、別のファイルセットの条件を満たすことができることを示します。 互換性エントリーは、ファイルセットが名前を変更したか、または 古くなったときに使用されます。 指定のファイルセットに置き換えられるのは、1 つのファイルセットだけです。 ユーザーがファイルセットごとに指定できる互換性エントリーは 1 つのみです。

lpp_name ファイルに入れることができるのは、ファイルセットごとに、多くても 1 つのバリア・エントリーと 1 つの互換性エントリーです。

バリア・エントリーは、非互換性が取り込まれたときのファイルセット名と ファイルセット・レベルから構成されます。 バリア・エントリーが必要なのは、あるファイルセットの先行のレベルに対する 条件が満足されないようになる程度まで、従属ファイルセットが必要とする機能が 変更されたか除去されたことによって、ファイルセットのある 1 つのレベル が非互換性を取り込んだ、というまれなケースが起こった場合に限られます。 バリア・エントリーは、ファイルセットのすべての後続のバージョンに 存在して、従属ファイルセットによって条件を満たすファイルセット の最新レベルを示す必要があります。

例えば、主な非互換性がファイルセット Bad.Idea 6.5.6.0 に 取り込まれた場合は、ファイルセット・レベル 6.5.6.0 以降 の Bad.Idea ファイルセット・インストール・パッケージの 置き換え情報セクションによって、 Bad.Idea 6.5.6.0 バリア・エントリーが入ります。 このバリア・エントリーによって、Bad.Idea 6.5.4.0 の必要条件は、6.5.6.0 以上の Bad.Idea のどのレベルでも満たされることはなくなります。

互換性エントリーは、ファイルセット名 (パッケージのファイルセット名とは異なる) および ファイルセット・レベルから構成されます。 ファイルセット・レベルは、指定されたファイルセットに対する条件が インストール・パッケージのファイルセットによって満たされる レベル (およびそのファイルセットの前のレベル) を識別します。 互換性は、指定されたファイルセットが古くなったか、または名前変更されたとき、および指定され たファイルセットの機能が現行ファイルセットに入っているときは役立ちます。 互換性エントリーのファイルセット・レベルは、指定されたファイルセットに存在すると予期 されるレベルより高いものである必要があります。

例えば、Year.Full 19.91.0.0 ファイルセットは、単位として引き渡されなくなり、代わりにいくつかの小さな個別のファイルセットに分割されます。 その結果のファイルセットの小さいほうの 1 つ (多分 Winter 19.94.0.0) のみに、Year.Full 19.94.0.0 の互換性エントリーが入っているはずです。 この互換性エントリーによって、Winter 19.94.0.0 ファイルセットは、19.94.0.0 より前のレベルで Year.Full に依存するファイルセットの必要条件を満たすことができます。

置き換え処理

installp コマンドは、ほかのファイルセットやファイルセット更新を 置き換える、ファイルセットおよびファイルセット更新を インストールするための特殊機能を備えています。

• インストール・メディアに、 ユーザーがインストールを要求したファイルセットまたはファイルセット更新が入っていない場合は、 インストール・メディア上の置き換えファイルセットまたはファイルセット更新をインストールすることができます。

  例えば、ユーザーは installp コマンドを -g フラグ (自動的に条件をインストールする) を指定して呼び出し、farm.apps.hog 4.1.0.2 ファイルセットをインストールします。 インストール・メディアに入っているのが farm.apps.hog 4.1.0.4 ファイルセットのみである場合、installp コマンドは farm.apps.hog 4.1.0.4 ファイルセットをインストールしますが、それはファイルセットが要求されたレベルを置き換えるためです。

• システムおよびインストール・メディアに必要条件のファイルセットまたはファイルセット更新が入っていない場合、必要条件は、置き換えのファイルセットまたはファイルセット更新によって満たすことができます。
• 更新がインストール時に要求され、-g フラグが指定されると、インストール・メディア上の最新の置き換え更新によって要求が満たされます。

  -g フラグが installp コマンドに指定されると、 インストールを要求された更新 (明示的か暗黙的のいずれか) は、インストール・メディア上の 最新の置き換え更新によって満たされます。 ユーザーは、更新の特定のレベル (必ずしも最新レベルではない) をインストールしたい場合は、-g フラグなしで installp コマンドを呼び出すことができます。

• 更新および置き換え更新 (ともにインストール・メディア上にある) がインストールを要求されると、installp コマンドは新しい更新のみをインストールします。

  このケースで、特定の更新とその置き換え更新をインストール・メ ディアから適用したい場合は、installp 操作を更新レベルごとに分けて行う 必要があります。 この種の操作は、2 つの更新が適用され、コミットされる場合 (-ac) は 意味がないので注意してください。 2 番目の更新をコミットすると、最初の更新はシステムから除去されます。

フィックス情報セクション

フィックス情報のセクションはオプションです。 フィックス情報セクション・エントリーには、1 つのフィックス・キーワードと、 解決する問題の 60 文字以下の説明が入ります。 フィックス・キーワードは、フィックスに対応する 16 文字以下の ID です。 ix、iy、IX、および IX で始まるフィックス・キーワードは、 オペレーティング・システム製造元用に予約済みです。

テクノロジー・レベルは、主要な更新レベルのフィックスです。 定期予防保守パッケージは、テクノロジー・レベルです。 テクノロジー・レベル ID は、ソフトウェア・プロダクト (パッケージではなく) の名前から始 まり、その後に単一ドット (.) と farm.4.1.1.0 などの識別レベルが付きます。

liblpp.a インストール制御ライブラリー・ファイル

liblpp.a ファイルは、パッケージ・インストールの制御に必要なファイルが入っている アーカイブ・ファイルです。 AIX 4.3 以上のシステム上で -g フラグを指定した ar コマンドを使って、 パッケージ用の liblpp.a ファイルを作成して、32 ビット・アーカイブが必ず作成されるようにすることができます。 この項では、liblpp.a アーカイブに入れることができる 多数のファイルについて説明します。

この項全体を通して、制御ファイルの名前中に Fileset が現れます。 Fileset は、ソフトウェア・パッケージ内にインストールされる個別のファイルセットの名前を表します。 例えば、適用リスト・ファイルは Fileset.al と名づけられます。 bos.net ソフトウェア・プロダクトの bos.net.tcp.client オプションの適用リスト・ファイルは、bos.net.tcp.client.al です。

このセクションで説明するファイルの多くは、オプショナルです。 オプショナル・ファイルが必要なのは、ファイルが提供する関数がファイルセット またはファイルセット更新に必要な場合に限られます。 特に断りがない限り、ファイルとは、完全なインストール・パッケージと ファイルセット更新パッケージの両方に関係します。

liblpp.a ファイルに入っているデータ・ファイル

liblpp.a ファイルに入っているオプションの実行可能ファイル

このセクションで説明する製品固有の実行可能ファイルは、インストール処理の際に コールされます。 特に断りがない限り、_i で終わるファイル名が使用されるのは インストール処理の間のみであり、_u で終わるファイル名が使用 されるのはファイルセット更新処理のときだけです。 この節で説明するファイルのすべては、オプショナルで、 シェル・スクリプトまたは実行可能オブジェクト・モジュールのどちらでも構いません。 プログラムで、インストールまたは更新を意図的に失敗させるのでなければ、 各プログラムの戻り値は 0 (ゼロ) でなければなりません。

Fileset.config または Fileset.config_u

デフォルトのインストール処理または更新処理の終わりに近くで構成を変更します。 Fileset.config が使用されるのは、 インストール処理の間だけです。

Fileset.odmdel または Fileset.*.odmdel

ファイルセットの新しい ODM エントリーを追加する前に、 ファイルセットの ODM データベース情報を更新します。 odmdel ファイル命名規則により、 ファイルセットは複数の odmdel ファイルを持つことができます。

Fileset .pre_d

アンインストール中にファイルセットを除去できるかどうかを示します。 ファイルセットを除去できる場合は、プログラムから 0 (ゼロ) の値を戻す必要があります。 ファイルセットは、デフォルトでは除去可能です。 プログラムは、ファイルセットが除去可能でない理由を示すエラー・メッセージを生成する必要 があります。

Fileset.pre_i または Fileset.pre_u

ファイルセットのインストール済みバージョンからファイルを除去した後に、かつ パッケージの適用リストのファイルを復元もしくは保存する前に実行します。

Fileset.pre_rej

ファイルセットのリジェクト操作の前、またはリジェクト操作のプレビューの前に 実行します。 スクリプトを使用して、このファイルセットがリジェクトできるかどうかを判別します。 このスクリプトは、システム上の何かを変更するようなコマンドを実行 するためには使用しないでください。 スクリプトがゼロ以外の戻りコードで終了した場合は、リジェクト操作は許されません。

Fileset.pre_rm

既にインストール済みのファイルセットのバージョンからファイルを除去する前の、 ファイルセットのインストールの際に実行します。

Fileset.post_i または Fileset.post_u

ファイルセットのインストールもしくは更新の適用リストから、ファイルを復元した後に実行します。

Fileset .unconfigFileset.unconfig_u

アンインストールまたはファイルセットのリジェクト中に、 インストールもしくは更新で実行された構成処理を元に戻します。 Fileset.unconfig が使用されるのは、 アンインストール処理のときのみです。

Fileset .unodmadd

インストールもしくは更新の際に ODM データベースに追加されたエントリーを削除します。

Fileset.unpost_i または Fileset.unpost_u

アンインストールまたはファイルセットのリジェクト中に、 インストールまたは更新の適用リストからファイルを復元してから、実行済みの処理を元に戻します。

Fileset.unpre_i または Fileset.unpre_u

アンインストールまたはファイルセットのリジェクト中に、 インストールまたは更新の適用リストからファイルを復元する前に、実行済みの処理を元に戻します。

これらの実行可能ファイルのどれかが、マシン上の入出力デバイス構成を変更する 可能性があるコマンドを実行する場合、その実行可能ファイルは、 コマンドを実行する前に、INUCLIENTS 環境変数を検査する必要があります。 INUCLIENTS 環境変数が設定されている場合は、コマンドを実行してはなりません。 ネットワーク・インストール管理 (NIM) 環境は、installp コマンドを多くの目的に使用します。 目的によっては、installp コマンドがその通常処理の一部を迂回しなければならない場合もあります。 NIM は、 この通常処理を迂回しなければならないときに、INUCLIENTS 環境変数を設定します。

このデフォルト・インストール処理がパッケージに対しては十分でない場合は、ユーザーは liblpp.a ファイルに以下の実行可能ファイルを提供することができます。 これらのファイルがパッケージで提供されていると、installp コマンドはパッケージが提供しているファイルを、システム・デフォルト・ファイルの代わりに使用します。 パッケージが 提供しているファイルには、デフォルト・ファイルと同じ機能が 入っている必要があります。入っていない場合は、想定外の結果を生じる恐れがあります。 デフォルト・ファイルをモデルとして使用すると、ユーザー独自のファイルを作成することができ ます。 パッケージが提供しているファイルに代わって このデフォルト・ファイルを使用するよう強くお勧めします。

instal

デフォルト・インストールのスクリプト /usr/lib/instl/instal の代わりに使用されます。 installp コマンドは、インストール・パッケージの ファイルセットが適用される場合に、この実行可能ファイルを呼び出します。

lpp.cleanup

デフォルトのインストール・クリーンアップ・スクリプト /usr/lib/instl/cleanup の代わりに使用されます。 installp コマンドは、インストール・パッケージまたは更新パッケージの ファイルセットが部分的に適用されていて、クリーンアップしてファイルセットを整合性 のある状態に戻す必要がある場合に、この実行可能ファイルを呼び出します。

lpp.deinstal

デフォルトのファイルセット除去スクリプト /usr/lib/instl/deinstal の代わりに使用されます。 この実行可能ファイルは、 /usr/lpp/PackageName ディレクトリー に入れてください。 installp コマンドは、インストール・パッケージの ファイルセットが除去される場合に、この実行可能ファイルを呼び出します。

lpp.reject

デフォルトのインストール・リジェクト・スクリプト /usr/lib/instl/reject の代わりに使用されます。 installp コマンドは、更新パッケージのファイルセット更新 がリジェクトされる場合に、この実行可能スクリプトを呼び出します。 (デフォルトの /usr/lib/instl/reject スクリプト は、/usr/lib/instl/cleanup スクリプトへのリンクです。)

update

デフォルトのファイルセット更新スクリプト /usr/lib/instl/update の代わりに使用されます。 installp コマンドは、更新パッケージのファイルセットが適用される場合 に、この実行可能ファイルを呼び出します。 (デフォルトの /usr/lib/instl/update スクリプト は /usr/lib/instl/instal スクリプトへのリンクです。)

Fileset.al ファイルに入っているオプションの実行可能ファイル

インストール制御ファイルの詳細 - Fileset.cfgfiles ファイル

Fileset.cfgfiles ファイルは、ユーザー構成のデータを失わずに新規バージョンのファイルセットに移行するために、保存する必要がある構成ファイルをリストします。 ユーザー構成データを保存するには、Fileset.cfgfiles ファイルを、適切な liblpp.a ファイル (ユーザーまたはルート) で指定する必要があります。

Fileset.cfgfiles には、保存するファイルごとに 1 行のエントリーが入っています。 エントリーごとに、ファイル移行の処理メソッドを記述した、ファイル名 (ルートを基準とする パス名)、ホワイト・スペース・セパレーター、およびキーワードが入っています。 処理メソッド・キーワードを、以下に示します。

preserve

ファイルのインストール済み新規バージョンを、 保存ディレクトリーの保存されたバージョンで置き換えます。 新規ファイルを保存されたバージョンで置き換えた後、構成保存ディレクトリーの 保存されたファイルは削除されます。

auto_merge

Fileset.post_i 処理の際、プロダクト提供の実行可能ファイルは、必要なデータを、ファイルのインストール済み新規バージョンから 構成保存ディレクトリーに保管された直前のバージョンのファイルにマージします。 Fileset.post_i 処理の後、installp コマンドは、ファイルのインストール済み新規バージョンを、構成保存ディレクトリーのマージ・バージョン (存在する場合) で置き換えてから、保存されたファイルを除去します。

hold_new

ファイルのインストール済み新規バージョンを、 保存ディレクトリーの保存されたバージョンで置き換えます。 新規バージョンのファイルは、古いバージョンに代わって構成保存ディレクトリー内に入れられま す。 ユーザーは、新規バージョンを参照 することができるようになります。

user_merge

インストール済み新規バージョンのファイルをシステム上に残し、 ファイルの古いバージョンを構成保存ディレクトリーに保有します。 ユーザーは、古いバージョンを参照して、 マージが必要な場合はそれを行うことができます。 可能なかぎり、このキーワードを使わないようにしなければなりません。

other

ほかの定義済み処理メソッドがいずれも十分なものでない場合に使用されます。 installp コマンドは、ファイルを構成保存ディレクトリーに保存し、それ 以上のサポートは行いません。 構成ファイルのほかの操作および処理は、すべてプロダクト提供の実行可能ファイルによって 行う必要があります。 ファイルの処理に関する文書の作成は、 プロダクト開発者が行います。

Fileset.post_i 実行可能ファイルは、 デフォルトのインストール処理では行えない構成データの特定の操作もしくはマージを行うときに使用することができます。

Fileset.cfgfiles ファイルにリストされている構成ファイルは、Fileset.cfgfiles ファイルに与えられているのと同じ相対パス名で、構成保存ディレクトリーに保存されています。 構成保存ディレクトリーの名前は、MIGSAVE 環境変数に保管されて います。 保存ディレクトリーは、 インストールされるパッケージの部分に対応しています。 以下のディレクトリーは、構成保存ディレクトリーです。

/usr/lpp/save.config

ユーザー部分用

/lpp/save.config

ルート部分用

保存の必要があるファイルのリストが、現在インストールされているファイルセットのレベルに応じて異なる場合は、Fileset.cfgfiles ファイルに、検出の可能性がある構成ファイルの全体のリストが入っている必要があります。 必要があれば、Fileset.post_i 実行可能ファイル (もしくは 他のプロダクトによって提供された実行可能ファイル) は、その相違に対処する必要があります。

例えば、構成可能なファイルが 1 つ含まれたファイルセット (change.rte) を持っているとします。 この場合、ルート change.rte.cfgfiles には、次のようにリストされたフ ァイルが 1 つあります。

/etc/change_user   user_merge

古いファイルセット (change.obj) から change.rte に移行するとき、フォーマットが変わっているためにこのファイルを保存しておくことはできません。 しかし、古いレベルの change.rte から新しいレベル change.rte に移行するときは、ファイルを保存しておくことができます。 この場合、どのファイルセットから移行を行うかを調べて、適切に行動する、 change.rte.post_i スクリプトを作成することができます。 このようにして、ユーザーが /etc/change_user ファイルに変更を加えた場 合は、その変更は保存されます。

#! /bin/ksh
rc=0
grep -q change.rte $INSTALLED_LIST
if [$? = 0]
then
mv $MIGSAVE/etc/change_user/ /etc/change_user
rc=1
fi
exit $rc

$INSTALLED_LIST は、installp によって作成され、エクスポートされます。 Fileset.installed_list 構成ファイルについての詳細は、再パッケージ化されたプロダクト専用のインストール制御ファイル を参照してください。 $MIGSAVE 変数には、ルート部分の構成ファイルが保存される ディレクトリーの名前が入っています。

installp コマンドは、Fileset.cfgfiles ファイルにリストされたファイルが検出されない場合は、警告もエラー・メッセージも生成しません。 installp コマンドは、保存された構成ファイルがその処理メソッドに従って処理 されるときは、Fileset.post_i 処理の後の フェーズの間に検出されないファイルに関してもメッセージを生成しません。 警告もしくはエラー・メッセージが必要ならば、プロダクト提供の実行可能ファイルがメッセージ を生成する必要があります。

./etc/cfg_leafpreserve
./etc/cfg_pudding hold_new
./etc/cfg_newtonpreserve

Fileset.fixdata ファイル

このファイルの情報は、フィックス・データベースに追加されます。 instfix コマンドはこのデータベースを使用して、システムにインストールされたフィックスを識別します。 Fileset.fixdata がパッケージに存在すると、フィックス・データベース内のフィックス情報は、パッケージの適用時に更新されます。

ファイルセット内の各フィックス は、Fileset.fixdata ファイル内に、 その独自のスタンザを持つ必要があります。 Fileset.fixdata スタンザのフォーマットを、次に示します。

fix:
name = FixKeyword
abstract = Abstract
type = {f | p}
filesets = FilesetName FilesetLevel
[FilesetName FilesetLevel ...]
[symptom = [Symptom]]

次の例は、問題 MS21235 の Fileset.fixdata スタンザを示しています。この問題のフィックスは、2 つのファイルセットに入っています。

fix:
name = MS21235
abstract = 82 gigabyte diskette drive unusable on Mars
type = f
filesets = devices.mca.8d77.rte 12.3.6.13
devices.mca.8efc.rte 12.1.0.2
symptom = The 82 gigabyte subatomic diskettes fail to operate in a Martian environment.

Fileset.inventory ファイル

Fileset.inventory ファイルは、ファイルをインストールもしくは更新するファイルセットの各部分に必要です。 パッケージのルート部分に、インストールするファイルが入っていない (構成しか入っていない) 場合、そのルート部分に Fileset.inventory ファイルは必要ありません。

注: Fileset.inventory ファイルは、サイズが 2 GB を超えるファイルをサポートしません。 2 GB を超えるファイルを出荷する場合は、 それを fileset.al ファイルに 組み込みますが、Fileset.inventory ファイルに 組み込んではなりません。 sysck は、2GB を超えるファイルは処理するように更新されておらず、 また、ほとんどのマシンの /usr ファイルシステムは、2GB を超える ファイルを処理できるようには作成されません (デフォルトによる)。

インベントリー・ファイルは、スタンザ・フォーマットの ASCII テキストから構成されます。 スタンザの名前は、インストールされるファイルの絶対パス名です。 スタンザ名は、コロン (:) で終わり、後に改行文字が付きます。 ファイル属性は、スタンザ名の後に続き、Attribute=Value のフォーマットをとります。 各属性の説明は、別の行で行われます。

inventory:
type     = type
class    = inventory,apply,C2_exclude,fileset
owner    = owner_name
group    = group_name
mode     = TCB | SUID | SGID,permissions
target   = fullpath_filename
link     = fullpath_to_hardlink [additional_hardlinks]
size     =<blank> | VOLATILE |size
checksum =<blank> | VOLATILE |"checksum"

fileset.inventory の例

以下の fileset.inventory の例は、type の使用法を示しています。

/usr/bin:
        owner = bin
        group = bin
        mode = 755
        type = directory
        class = apply,inventory,bos.rte


/usr/bin/tcbck:
        owner = root
        group = security
        mode = TCB,SUID,550
        type = file
        class = apply,inventory,bos.rte.security
        size = 99770
        checksum = "17077     98 "


/usr/sbin/tsm:
        owner = root
        group = security
        mode = TCB,SUID,555
        links = /usr/sbin/getty,/usr/sbin/login
        class = apply,inventory,bos.rte,security
        size = 55086
        checksum = "57960     54 "

パッケージ化されたプロダクト専用のインストール制御ファイル

Fileset.installed_list

パッケージからファイルセットをインストールする際に、ファイルセット (または ある形式のファイルセット) があるレベルのシステムに 既にインストール済みであることが分かった場合に、 installp コマンドによって作成されるファイル。

Fileset か、または ファイル Fileset.namelist (存在している 場合) にリストされているファイルセットのいずれかが既にシステム上にインストール されているかを判別する場合は、ソフトウェア情報データベースが検索されます。 インストールされている場合は、ファイルセットおよびインストール・レベル が Fileset.installed_list ファイル に書き込まれます。

Fileset.installed_list ファイルには、インストールされたファイルセットごとに 1 行のエントリーが入っています。 どのエントリーにも、ファイルセット名とファイルセット・レベルが入ってい ます。

storm.rain 1.1.0.0

Pelly.com
GooseCreek.rte
CedarBayou.stream 

Pelly.obj 1.2.3.0
CedarBayou.stream 4.1.3.2

Fileset.namelist ファイルは、liblpp.a ファイルの usr 部分または root 部分に提供される必要があります。 Fileset.namelist ファイル は、インストール・パッケージの場合のみ有効です。更新パッケージには無効です。

インストールの最初に、installp コマンドは、ソフトウェア重要プロダクト・データ (SWVPD) を検索して、このファイルセット、もしくは Fileset.namelist ファイルにリストされたファイルセットが、システムに既にインストール済みであるかどうかを判別します。 installp コマンドは、Fileset.installed_list ファイルに、インストールが確認されたファイルセット名とファイルセット・レベルを書き込み、この情報をプロダクト提供の実行可能ファイルが使用できるようにします。

family.business

lawoffice.mgr

lawoffice.mgr
BusinessOffice.mgr

Fileset.namelist ファイルに入っているエントリーが 1 つのみで、かつ現行ファイルセットが、Fileset.namelist ファイルにリストされたファイルセットの直接の置き換えでない場合は、Fileset.rm_inv ファイルを liblpp.a ファイルに組み込む必要があります。 インストール処理では、 Fileset.namelist ファイルと Fileset.rm_inv ファイルを用いて、ファイルセットが、別のファイルセットの直接の置き換えであるかどうかを判別します。 Fileset.namelist ファイルに入っているエントリーが 1 つのみで、Fileset.rm_inv ファイルがない場合、インストール処理は、新規ファイルセットを古いファイルセットの直接の置き換えと見なします。 新しい (置き換え) ファイルセットのインストールの際、インストール処理は、 古い (置き換えられる) ファイルセットからのすべてのファイルを、(新規ファイルセット に組み込まれていないファイルであっても) システムから除去します。

前掲の例で、small.business ファイルセットは、family.business ファイルセットの直接の置き換えなので、small.business.rm_inv ファイルは存在していてはなりません。 LawPractice.client ファイルセットは、lawoffice.mgr ファイルセットの直接の置き換えではなく、したがって LawPractice.client.rm_inv ファイルは、たとえ空であっても、存在していなければなりません。

例 3:

bread.shop.rte
bagel.shop.rte

さらに、空の bread.shop.rte.rm_inv ファイルを出荷して、 bagel.shop.rte ファイルセットのファイルをすべてシステムから除去すべきことを示 す必要もあります。

このファイルは、現行ファイルセットが前レベルのファイルセットと異なる方法でパッケージ化され、インベントリー・データベース内のファイルセットのエントリーに基づいて以前にインストールされたファイルをインストール・プロセスで削除してはならない場合に使用されます。

単にファイルセットの名前を変更しただけでは、 Fileset.rm_inv ファイルを要求するには不充分です。 新規サブセットが、先行のファイルセットのサブセットであるか、または 先行のファイルセットの部分の混合であるかのいずれかであるとき は、Fileset.rm_inv ファイルが必要です。 Fileset.namelist ファイルが存在し、このファイルに複数のファイルセットのエントリーが入っている場合は、Fileset.rm_inv ファイルを用いて、以前にインストールされたレベルのファイルをシステムから除去する必要があります。

Fileset.rm_inv ファイルは、スタンザ・フォーマットの ASCII テキストで構成されます。 スタンザの名前は、システム上で検出された場合は除去される、ファイルまたはディレクトリーの 絶対パス名です。 スタンザ名は、コロン (:) で終わり、後に改行文字が付きます。 スタンザ名の後に属性が付く場合、その属性 は Attribute=Value の フォーマットをとります。 属性は、除去の必要があるハードリンクおよびシンボリック・リンクの識別に使用します。 各属性の説明は、別の行で行われます。 次のリストでは、示されているファイルに関連付けられた有効な属性を説明します。

例えば、U.S.S.R 19.91.0.0 ファイルセットには、/usr/lib ディレクトリー内のファイル、 すなわち、moscow、leningrad、kiev、odessa、および petrograd (leningrad へのシンボリック・リンク) が入っています。 プロダクト開発者は、U.S.S.R 19.91.0.0 ファイルセットを、2 つのファイルセット、すなわち Ukraine.lib 19.94.0.0 と Russia.lib 19.94.0.0 に分割するように決めます。 Ukraine.lib ファイルセットには、kiev ファイルおよび odessa ファイルが入っています。 Russia.lib ファイルセットには moscow ファイルが入っています。 leningrad ファイルは存在 しなくなり、Russia.lib ファイルセット の st.petersburg ファイルによって置き換えられます。

Ukraine.lib.rm_inv ファイルは、 Ukraine.lib ファイルセットが U.S.S.R ファイルセットの直接の置き換えではないため、存在する 必要があります。 Ukraine.lib.rm_inv ファイルは空にしてください、というのも、Ukraine.lib ファイルセットが、移行 U.S.S.R ファイルセットをクリーンアップするためにインストールされる時、どのファイルも除去する必要はないからです。

/usr/lib/leningrad:
 symlinks = /usr/lib/petrograd
/usr/lib/petrograd:

補足ディスク・サブシステム用のインストール・ファイル

提供された SCSI またはバス接続のデバイス・ドライバーによって構成しない ディスク・サブシステムには、独自のデバイス・ドライバーと構成メソッドが必要です。 これらのインストール・ファイルは、補足ディスケット (デバイスに付いている) で 提供され、./signature ファイルと ./startup ファイルが含まれるバックアップ・フォーマットでなければなりません。 署名ファイルには、target の文字列が入っていなければなりま せん。 スタートアップ・ファイルは、名前による復元機能を使用して、必要なファイルを補足ディスケットから抽出し、デバイスを使用可能状態にするために必要なコマンドを実行する必要があります。

配布メディアのフォーマット

ソフトウェア・プロダクトのインストール・パッケージを配布するときは、 以下のタイプのメディアを使用することができます。

以下のセクションで、これらの各メディアで複数のプロダクト・パッケージを配布する際に使用する必要のあるフォーマットについて説明します。

テープ

複数のプロダクト・パッケージ・イメージを単一テープまたはテープのセットにスタックするために、セット内の各テープ上のファイルは以下のフォーマットに準拠していなければなりません。

• ファイル 1 は空。 (ブート可能テープに予約済み。)
• ファイル 2 は空。 (ブート可能テープに予約済み。)
• ファイル 3 には、テープのセット上のプロダクト・パッケージ・イメージを 説明する目次ファイルが入っています。 したがって、セット内の各テープには、同じ目次ファイルの コピー (マルチボリューム・セットの場合はテープ・ボリューム番号だけが異なる) が入っています。
• ファイル 4 から (N+3) には、 1 から N のプロダクト・パッケ ージのバックアップ・フォーマットのファイル・イメージが入っています。
• プロダクト・パッケージのイメージ・ファイルは、2 つのテープにわたっていてはなりません。
• 各ファイルの後には、ファイルの終わりテープ・マークが付きます。

CD-ROM

複数のプロダクト・パッケージ・イメージを収める ための CD-ROM は、Rock Ridge Group プロトコルに準拠する必要があります。 プロダクト・パッケージはインストール・ディレクトリーに保管されます。 このディレクトリーには以下が含まれている必要があります。

• プロダクト・パッケージのバックアップ・フォーマットのファイル・イメージ
• ディレクトリー内のプロダクト・パッケージ・イメージを記述する、.toc という目次ファイル。

マルチボリューム CD-ROM は、1 セットの CD-ROM を単一のインストール可能単位として定義するための追加ディレクトリー構造を持つ CD-ROM です。

AIX 5.2例:

ファイル A はボリューム 1 のファイル A.bff に入っていて、ファイルセット B はボリューム 2 のファイル B.bff に入っています。A および B の製品 パッケージ・イメージの位置が入っている /installp/mvCD 内の音量 ファイルのフィールドは、それぞれ vol%1/A.bff と vol%2/B.bff です。 ボリューム 1 の /installp/ppc 内の目次ファイル のフィールドには、A の位置が A.bff として入っています。 ボリューム 2 の /installp/ppc 内の目次ファイル のフィールドには、B の位置が B.bff として入っています。

AIX 5.1 以降の CD-ROM のディレクトリー構造では、他のインストーラーと複数のプラッ トフォームの指定が可能です。

ディスケット

複数のプロダクト・パッケージ・イメージを 1 セットのディスケットにスタックするためには、以下のファイルをディスケットのセットに書き出す必要があります。

• セットに組み込むプロダクト・パッケージ・イメージを記述する 目次ファイル。
• セットに組み込む各プロダクト・パッケージ・イメージ・ファイル。

ファイルは、以下の規則を用いて、ディスケットのセットに書き出されます。

• セット内の各ディスケットのブロック 0 にボリューム ID セクターを挿入して、 ディスケット・セットにストリームとしてデータを書き出す。 1 つのボリュームの最後のブロックからのデータは、次のボリュームのブロック 1 からの データに論理的に隣接するものとして扱われます (ボリューム ID セクターが確認され、 読み取られると破棄される)。
• 各ファイルは 512 バイト・ブロック境界から始まる。
• 最初に目次ファイルを書き出す。 このファイルの最後のセクターに null 文字 (x'00') を埋め込みます。 目次ファイルの終了をマークするには、少なくとも 1 つの null 文字が必要です。 したがって、全部 null 文字のセクターが必要な場合があります。
• 目次ファイルの次に、プロダクト・パッケージのイメージ・ファイル のそれぞれを、連続したセクターに書き出す。 各ファイルの最後のセクターに、null 文字を埋め込みます。 ファイルがブロック境界で終わる場合、null 文字は不要です。
• セット内の各ディスケットのブロック 0 に、ボリューム ID セクターが入る。 このセクターのフォーマットを、以下に示します。

  位置	説明
  バイト 0:3	識別用のマジック・ナンバー。 これは、値が 10 進 3609823513=x'D7298918' の 2 進整数。
  バイト 4:15	ディスケットのセットの識別用に使用される、日付と時刻のスタンプ (ASCII での)。 フォーマットは MonthDayHourMinuteSecondYear です。 Hour は 00 から 23 の値でなければなりません。 すべての日付と時刻のフィールドには 2 桁の数字が入ります。 したがって、Month は 3 では なく 03、Year は 1994 では なく 94 で表す必要があります。
  バイト 16:19	このセットのディスケット内の 2 進整数のボリューム番号。 セット内の最初のディスケットは x'00000001' に設定されます。
  バイト 20:511	2 進ゼロ。

日付と時刻のタイム・スタンプ形式

日付と時刻のタイム・スタンプ形式は、次の形式の ASCII 文字列です。

MonthDayHourMinuteSecondYear

Hour は 00 から 23 の値でなければなりません。 すべての日付と時刻のフィールドには 2 桁の数字が入ります。 したがって、Month は 3 では なく 03、Year は 1994 では なく 94 で表す必要があります。

テープおよびディスケットの位置フォーマット

位置のフォーマットは vvv:bbbbb:sssssss です。ここで、各文字は数字を表し、以下の意味を持っています。

テープの場合

vvv

は、テープのボリューム番号です。

bbbbb

は、プロダクト・パッケージ・イメージのテープのファイル番号です。

ssssssss

は、バイト単位のファイルのサイズです。

ディスケットの場合

vvv

は、ディスケットのボリューム番号です。

bbbbb

は、プロダクト・パッケージ・イメージ・ファイルが始まるディスケット上のブロック番号です。

ssssssss

は、バイト単位のファイルのサイズです (ブロック境界の終わりまでの埋め込みを含む)。

AIX 再配置可能インストール

AIX 再配置可能インストールは現在、ネイティブの AIX インストール・ユーティリティー (installp、instfix、lslpp、lppchk など) でサポートされていますが、ワークロード区画内にインストールする必要があるアプリケーションにとって、再配置の使用は特に重要です。 これはデフォルトの System WPAR 構成に書き込み可能な /usr または /opt ファイルシステムがないためです。 このため、アプリケーションのインストールは、従来の /usr または /opt ロケーション以外のロケーションをターゲットにする必要があります。

用語

ルート・インストール・パス

アプリケーションがインストールされるベース・ディレクトリー。 installp デフォルト・インストール・パスは "/" です。

デフォルト・インストール・パス

デフォルトのルート・インストール・パス (すなわち、"/" です)。

再配置インストール・パス

デフォルト・インストール・パスではないルート・インストール・パス。 このパス・ロケーションは、"/" ではない、サイズが 512 文字を超えない任意の有効なパスです。

再配置可能アプリケーション

デフォルト以外のルート・インストール・パスにインストールできるアプリケーション。

USIL (ユーザー指定のインストール位置)

ユーザーが設定する再配置インストール・パス・インスタンス。

USIL

ユーザー指定のインストール・ロケーション (USIL) は、管理者が作成する、追跡対象の再配置インストール・パスです。 このロケーションは、システムにより追跡され、再配置をサポートするパッケージの代替のインストール・パスとして使用できます。 各インストールを別個の USIL に委託することにより、同一ソフトウェア・パッケージの複数のインスタンスやバージョンを単一のシステムにインストールします。 既存の USIL インスタンスを指定のシステムに付加するか、指定のシステムから分離できます。

USIL 管理コマンド

/usr/sbin/mkusil

新規 USIL インスタンスを作成または付加します。

mkusil -R RelocatePath -c Comments [X Fa]

-a

既存のインストールを USIL インスタンスとして付加します。

-c

USIL 定義に含めるコメント (lsusil コマンドで表示可能)

-R

新規 USIL ロケーションへのパス。 有効なディレクトリーでなければなりません。

-X

必要なスペースの自動拡張

/usr/sbin/lsusil

既存 USIL インスタンスをリストします。

lsusil [-R RelocatePath | "ALL"]

-R

既存 USIL ロケーションへのパス。

/usr/sbin/rmusil

既存 USIL インスタンスを除去します。

rmusil -R RelocatePath

-R

既存 USIL ロケーションへのパス。

/usr/sbin/chusil

既存 USIL インスタンスの属性を変更します。

chusil -R RelocatePath -c NewComments [ X]

-c

USIL 定義に含める新規コメント (lsusil コマンドで表示可能)

-R

既存 USIL ロケーションへのパス。

-X

スペースが必要な場合に自動的に拡張

再配置可能インストール・ユーティリティー

再配置可能アプリケーションのパッケージ化要件

再配置可能アプリケーションの実行要件

USIL コネクター ODM クラス・オブジェクト

USIL コネクター ODM クラス・オブジェクトは、/etc/objrepos/usilc ファイル内にあり、デフォルトの SWVPD をすべての USIL インスタンスとリンクするデータを持ちます。

/*  User Install Location Connector                                    */
/*  Connects the default install path to all relocated install paths.  */
class   usilc {
        vchar   path[1024];             /* USIL path */
        vchar   comments[2048];   /* USIL Comments */
        long    flags;                       /* USIL flags */
        };     

-R "ALL" オプションまたは -R "all" オプションを使用したすべてのインストール・パスのリスト

-R "ALL" 構文を使用すると、lslpp コマンドと lppchk コマンドはすべてのインストール・ロケーションでリスト操作を実行できます。

付加/分離の操作

付加操作では、ユーザーは既存の分離 USIL パスを SWVPD に統合することができます。

例えば、管理者がアプリケーション・ホスティング用にインストールされたさまざまな再配置可能アプリケーションでマスター USIL インスタンスを作成するとします。 この場合、管理者はこの USIL インスタンスをさまざまなシステムにコピーまたは NFS マウントし、付加機能を使用して USIL インスタンスを SWVPD に統合します。 分離操作では、USIL インスタンスへの参照が除去されます。

installp ライセンス交付

新規 USIL インスタンスは、空の LAG (installp 使用許諾契約 ODM オブジェクト・クラス) から開始します。 ライセンスを必要とするファイルセットまたは LPP のインストールでは、通常の installp 規則に応じたライセンスの許諾が必要です。 ライセンスの許諾では、USIL インスタンスは拡張されません。

トラステッド・コンピューティング・ベース (TCB)

USIL インスタンスのインストールは、TCB 対応システムでは現在サポートされていません。

再配置可能の必要条件

新しいパッケージ化のセマンティックは、再配置可能の必要条件のロケーションを示します。 パッケージャーは、指定の必要条件をデフォルト・インストール・パスまたは再配置インストール・パスで検出されるように指定できます。

現在定義されている必要条件タイプ (prereq、ifreq、coreq、および instreq) は、すべてデフォルトの必要条件です (デフォルト・インストール・ロケーションに適用される要件)。

再配置可能パッケージの TOC 変更

sscp.rte.1.0.0.5.U.PRIVATE.bff 4 R S sscp {
sscp.rte 01.00.0000.0005 1 N B En_US Sscp
[
*coreq bos.games 1.1.1.1  <-- default requisite in default requisite section
*prereq bos.rte 1.1.1.1   <-- default requisite in default requisite section
%
/usr/bin 20
/etc 20
INSTWORK 72 40
%
%
%
IY99999  1 APAR text here.
%
RELOCATABLE <-- attribute tag to denote relocatable package
%
*prereq bos.rte 1.1.1.1 <-- default requisite in relocated requisite section
*coreq_r bos.games 1.1.1.1 <-- relocated requisite in relocated requisite section
]
}

プロダクト・パッケージ内にある実行可能ファイルは、適用操作、リジェクト操作、および削除操作の処理を調整することができます。

ファイルセットを再インストールすることは、同じファイルセットを除去してインストールする場合と 同じアクションを行うことではありません。 再インストール・アクション (/usr/lib/instl/rminstal を参照) では、現在のファイルを直前のもしくは同じバージョンからクリーンアップしますが、unconfig スクリプトまたは unpre* スクリプトはいずれも実行しません。 したがって、unconfig スクリプトが実行されたとは見なさないでください。 unconfig が完了したと見なす前に、.config スクリプトは、 環境を検査する必要があります。

例えば、ras.berry.rte ファイルセットの場合、config スクリプトはルートの crontab ファイルに 1 行追加します。 ras.berry.rte ファイルセットを再インストールすると、unconfig スクリプトが再インストール (crontab エントリーを除去した) で実行されなかったため、2 つの crontab エント リーが生じます。 config スクリプトは、必ずエントリーを除去してから、それを再度追加する必要があります。

適用操作の処理

この項では、ファイルセットまたはファイルセット更新が適用される際に installp コマンドがとるステップについて説明します。

1. 指定したデバイスから、パッケージ の lpp_name プロダクト・パッケージ情報ファイルを復元します。
2. 要求されたファイルセットがインストール・メディアに存在することを検査します。
3. 要求されたファイルセットのレベルを検査して、システムにインストールできることを確認します。
4. liblpp.a アーカイブ・ライブラリー・ファイルからの制御ファイルを、package directory に復元します (usr パッケージまたは usr/root パッケージの場合は /usr/lpp/Package_Name。特に usr/root パッケージの root 部分の制御ファイル は、/usr/lpp/Package_Name/inst_root/liblpp.a に 常駐しています)。
5. ディスク・スペース要件を検査します。
6. 必要な条件 (別のファイルセットを使用もしくはインストールするために特定のレベルになければならないファイルセット) が既にインストール済みか、あるいはインストールするリスト上にあるかを検査します。
7. インストールを先に進める前に満たすべきご使用条件の要件があるかどうかを判別します。
8. これがファイルセット更新パッケージではなくインストール・パッケー ジである場合、ソフトウェア重要プロダクト・データ (SWVPD) を検索して、 Fileset (インストールされるファイルセット) または Fileset.namelist ファイルにリストされてい るファイルセットが、既にいずれかのレベルでシステムにインストールされているかどうかを調 べます。 Fileset が既にインストール済みならば、ファイルセット名とインストールされたレベルを Work_Directory/Fileset.installed_list ファイルに書き込みます。

   どのレベルの Fileset もインストールされていない場 合に、Fileset.namelist ファイルにリストされたファイルセットがインストールされていれば、 Work_Directory/Fileset.installed_list ファ イル内のこれらのファイルセットとレベルをすべてリストします。 Work_Directory はパッケージ・ディレクトリーと同じですが、root 部分は例外で、/lpp/Package_Name を使用します。

9. これが、ファイルセット更新パッケージではなくインストール・パッケ ージならば、/usr/lib/instl/rminstal スクリプトを実行して 、インストールされるファイルセットごとに以下のことを行います。
   注: 他に指定がない場合、存在を検査されるファイル は、liblpp.a 制御ファイル・ライブラリーから復元されていなければなりませ ん。
   1. Fileset.pre_rm が存在する場合は、Fileset のこのバージョンまたは既存のバージョンからファイルを除去する前に、Fileset.pre_rm を実行して、必要なステップを行います。
   2. Work_Directory/ Fileset.installed_list が存在する場合は、 Fileset.cfgfiles にリストされた既存のファイルを構成ファイル 保存ディレクトリー (MIGSAVE 環境変数によって指示されたもの) に移動します。
   3. Fileset のバージョンが既にインストール済みならば、Fileset のファイルおよび SWVPD 情報を除去します (ヒストリーを除く)。
   4. Work_Directory/Fileset.installed_list が存在し、しかも Fileset.rm_inv が存在する か、または Fileset.namelist に複数のファイルセットが入っているか、または Fileset.namelist にリストされた唯一のファイ ルセットが bos.obj である場合、次のようにします。
      1. ファイル Fileset.rm_inv にリストされて いるファイルの、ファイルと SWVPD インベントリーの情報を除去する。
      2. ファイル Fileset.inventory にリストされて いるファイルの、ファイルと SWVPD インベントリーの情報を除去する。
      3. もはや SWVPD インベントリー情報を持っていない Fileset.namelist にリストされている、ファイルセットの他の SWVPD 情報を除去する。
   5. Work_Directory/Fileset.installed_list が存在し、しかもファイルセットを 1 つだけ収容していて、 Fileset.namelist にはファイルセットが 1 つ だけ入っていた場合は、そのファイルセットに関するファイルと SWVPD 情報 (ヒストリーは除く) を除去します。
   6. プロダクト・パッケージの各部分 (usr 部分の み、または usr 部分とその後に続く root 部分) ごとに、
      1. INUTREE (usr の場合は U、root の場合は M)、および INUTEMPDIR (作成された一時作業ディレクトリーの名前) 環境変数を設定する。
      2. instal 制御プログラムが、パッケージ・ディレクトリーに存在する場合は (お勧めしませんが)、 ./instal を実行するか、 あるいは、デフォルトのスクリプト /usr/lib/instl/instal を実行します。 instal 制御プログラムがパッケージ・ディレクトリー内に存在しない場合は、 INUSAVEDIR 環境変数を設定します。
      3. update 制御プログラムが、 パッケージ・ディレクトリーに存在する場合は (お勧めしませんが)、 ./update を実行します。 update 制御プログラムがパッケージ・ディレクトリー内に存在しない場合は、 デフォルトのスクリプト /usr/lib/instl/update を実行します。
      4. status ファイルが instal または update によって正常に作成された場合は、 status ファイルを使用して、各ファイルセットの成功または失敗を判別します。 status ファイルが作成されなかった場合は、 パッケージ内の要求されたすべてのファイルセットが適用に失敗したと見なします。
      5. ファイルセットの適用操作が正常に終了した場合は、 ソフトウェア重要プロダクト・データ (SWVPD) を更新し、関連したご使用条件を登録します。 ファイルセットの適用操作が正常に終了しなかった場合は、 /usr/lib/instl/cleanup を実行するか、またはパッケージで提供されている lpp.cleanup をパッケージ・ディレクトリーから実行して、 失敗したファイルセットをクリーンアップします。

デフォルトのインストール・スクリプトまたは更新スクリプトの処理

instal 実行可能プログラムまたは update 実行可能スクリプトは、インストールまたは更新に使用されるデバイスである最初のパラメーターによって installp から呼び出されます。 2 番目のパラメーターは、インストールまたは更新するファイルセットのリスト (以下で $FILESETLIST と呼ばれる) が入っているファイルに対する絶対パス名です。 デフォルトの instal スクリプトおよび update スクリプトは、相互にリンクされています。処理は、instal で呼び出されるか、update で呼び出されるかによって異なります。現行ディレクトリーはパッケージ・ディレクトリーです。 /tmp で一時ディレクトリー INUTEMPDIR が作成され、作業ファイルを保持 します。

デフォルトの instal および update スクリプト内の流れを、以下に示します。

1. $FILESETLIST にリストされたファイルセットごとに、以下のことを行います。
   1. ファイルセットが更新の場合、 Fileset.pre_u (pre_update) が存在すれば、それを実行する。 ファイルセットが更新でない場合、 Fileset.pre_i (pre_installation) が存在すれば、 それを実行する。
   2. Fileset.al を 新規ファイル INUTEMPDIR/master.al に追加することによって、 パッケージから復元するファイルのマスター・リストを作成する。
   3. これが更新で、ファイルが保管されるよう指定されており、 lpp.acf アーカイブ制御ファイルが存在する場合は、

      更新するライブラリー・アーカイブ・メンバーから離して保存する。

   4. 処理が成功したら、このファイルセットを、 $FILESETLIST.new ファイルにインストールするリストに付加する。
2. これが更新で、 ファイル保管が指定されている場合は、inusave を実行して、ファイルの現行バージョンを保存します。
3. ルート部分を処理している場合は、inucp を実行して、ファイルを適用リストからルート部分にコピーします。 ルート部分を処理していない場合は、inurest を実行して usr 部分の適用リストからファイルを復元します。
4. $FILESETLIST.new ファイルにリストされたファイルセットごとに、以下のことを行います。
   注: どのステップでの失敗 も status ファイルに記録され、そのファイルセットの処理は終わります。
   1. このファイルセットのインストールが新旧いずれのレベルで行われてい るかや、または Fileset.namelist にリ ストされているファイルセットがインストールされているかどうかを判別する。 インストールされている場合は、INSTALLED_LIST 環境変数と MIGSAVE 環境変数をエクスポートする。 この処理は、移行 と呼ばれます。
   2. 更新を処理している場合、 Fileset.post_u が存在すれば、それを呼び出す。 Fileset.post_u が存在しない場合、 Fileset.post_i が存在すれば、それを呼び出す 。
   3. Fileset.cfgfiles が存在する場合、 指定された処理方法にしたがって構成ファイルの処理を扱うために、 /usr/lib/instl/migrate_cfg を実行する。
   4. sysck を呼び出して、 Fileset.inventory ファイル内の情報を、ソフ トウェア重要プロダクト・データベース (SWVPD) に追加する。
   5. Fileset.tcb ファイルが 存在し、 /usr/lib/objrepos/PdAt ODM データベースに、 トラステッド・コンピューティング・ベースの tcb_enabled 属性が 設定されている場合は、tcbck コマンドを呼び出して、 トラステッド・コンピューティング・ベース情報をシステムに追加する。
   6. Fileset.err が存在 する場合は、errupdate を呼び出して、エラー・テンプレートを追加する 。
   7. Fileset.trc が存在 する場合は、trcupdate を呼び出して、トレース・レポート・フォーマット のテンプレートを追加する。
   8. 更新が存在するか、 または Work_Directory/ Fileset.installed_list が存在する場合は、各 Fileset.odmdel および Fileset.*.odmdel スクリプトを呼び出して、 ODM データベース削除コマンドを処理する。
   9. 既存の各 Fileset.odmadd および Fileset.*.odmadd で odmadd を 呼び出して、情報を ODM データベースに追加する。
   10. これが更新の場合、 Fileset.config_u (ファイルセット構成の更新) が存在すれば、 それを呼び出す。 そうでない場合は、 Fileset.config (ファイルセット構成) があれば、それを呼び出す。
   11. ファイルセットの処理が成功したことを 示す、status ファイルを更新する。
5. ファイルセットの除去に必要な制御ファイルを、将来の利用に備えて、 パッケージの deinstl ディレクトリーにリンクします。 これらのファイルの中には、パッケージ・ディレクトリーに存在している場合がある以下のファイ ルがあります。
   • lpp.deinstal
   • Fileset. al
   • Fileset. inventory
   • Fileset. pre_d
   • Fileset. unpre_i
   • Fileset. unpre_u
   • Fileset. unpost_i
   • Fileset. unpost_u
   • Fileset. unodmadd
   • Fileset. unconfig
   • Fileset. unconfig_u
   • $SAVEDIR/Fileset. *.rodmadd
   • SAVEDIR/Fileset. *.unodmadd

リジェクト操作およびクリーンアップ操作の処理

このセクションでは、ファイルセット更新がリジェクトされたとき、あるいは ファイルセットまたはファイルセット更新がインストールを完了できなかった ときに、installp コマンドがとるステップについて説明します。 /usr/lib/instl にあるデフォルトの cleanup スクリプトと reject スクリプトは、相互にリンクされます。 両者の論理は、スクリプトが reject として呼び出されたか、 または cleanup として呼び出されたかによってわずかに異なります。 usr/root ファイルセットまたは ファイルセット更新の場合、root 部分 は、usr 部分より前に処理されます。

1. リジェクトの場合は、必要条件を検査して、従属プロダクト更新もすべてリジェクトされることを確認します。
2. プロダクト・パッケージの各部分 (例えば、usr および root) ごとに、
   1. INUTREE (usr の場合は U、root の場合は M)、および INUTEMPDIR 環境変数を設定する。
   2. reject 制御ファイルが、 現行ディレクトリー (INULIBDIR) に存在する場合は、./lpp.reject を実行する。 そうでない場合は、デフォルトのスクリプト /usr/lib/instl/reject を実行する。
3. ソフトウェア重要プロダクト・データを更新します。

reject 実行可能スクリプトは、最初のパラメーターを定義せず、2 番目の パラメーターが絶対パス名である installp から、 更新のためにリジェクトされるファイルセットのリスト (以下 で、$FILESETLIST と呼ばれる) が入っているファイルに呼び出されます。

以下のファイルは、 デフォルトの cleanup および reject スクリプト によって参照されます。

デフォルトの cleanup および reject スクリプト内の流れを、以下に示します。

1. $FILESETLIST にリストされたファイルセットごとに以下のことを行います。
   1. cleanup として呼び出された場合は、Package_Name.s 状況ファイルの行を読み取って、インストールが失敗したステップを判別し、そのステップの元に戻すアクションにスキップして進む。 cleanup 操作は、インストールが失敗したステップからのみ始まります。 例えば、ファイルセットのインストールが Fileset.post_i スクリプトで失敗すると、インストールのその後のステップからは元に戻すアクションがないため、そのファイルセットのクリーンアップ操作は、i で始まります。
   2. インストールの際に行われたすべての構成処理を元に戻す。

      更新を拒否する場合、 Fileset.unconfig_u が存在すれば、それを呼び出す。 そうでない場合、 Fileset.unconfig が存在すれば、それを呼び出す。

   3. Fileset.*.unodmadd ファイル または Fileset.unodmadd ファイル (あるいはその両方) を 実行して、インストールの際に追加されたオブジェクト・データ・マネージャー (ODM) エントリーを除去する。
   4. Fileset.*.rodmadd または Fileset.rodmadd (あるいはその両方) を実行して、インストールの際に削除された ODM エントリーを置き換える。
   5. Fileset.undo.trc が 存在する場合は、trcupdate を呼び出して、インストールの際に行われた トレース・フォーマット・テンプレートの変更を元に戻す。
   6. Fileset.undo.err が 存在する場合は、errupdate を呼び出して、 インストールの際に行われたエラー・フォーマット・テンプレートの変更を元に戻す。
   7. /usr/lib/objrepos/PdAt ODM データベースに、Fileset.tcb ファイルが存在し、トラステッド・コンピューティング・ベース属性 tcb_enabled が設定されている場合は、tcbck を呼び出して、システムへのトラステッド・コンピューティング・ベース情報を削除する。
   8. Fileset.inventory が存在す る場合は、sysck を呼び出して、ソフトウェア情報データベースに対する 変更を元に戻す。
   9. インストールの際に行われた post_installation 処理があれば、元に戻す。

      これが更新の場合、 Fileset.unpost_u が存在すれば、それを呼び出す。 そうでない場合、 Fileset.unpost_i が存在すれば、それを呼び出す。

   10. Fileset.al ファイルからマスター適用リスト (master.al と呼ばれる) を作成する。
   11. Fileset を $FILESETLIST.new に 追加する。
2. $INUTEMPDIR/master.al が存在する場合は、以下のことを行います。
   1. ディレクトリーを / (root) に変更する。
   2. master.al 内のすべてのファイルを除去する。
3. $FILESETLIST.new を読み取る間に、以下のことを行います。
   1. inurecv をコールして、保存されたファイルのすべてを 回復する。
   2. これが更新の場合、 Fileset.unpre_u が存在すれば、それを呼び出す。 そうでない場合、 Fileset.unpre_i が存在すれば、それを呼び出す。
   3. インストール/更新制御ファイルを削除する。
4. Package_Name.s 状況ファイルを除去します。

除去操作の処理

このセクションでは、ファイルセットが除去される際に、installp コマンドがとるステップについて説明します。 usr/root ファイルセットまたは ファイルセット更新の場合、root 部分 は、usr 部分より前に処理されます。

1. 必要条件を検査して、従属ファイルセットもすべて削除されることを確認します。
2. プロダクト・パッケージの各部分 (例えば、usr および root) ごとに、次のようにします。
   1. INUTREE (usr には U、root には M、および share には S) ならびに INUTEMPDIR (/tmp で生成された installp 作業ディレクトリー) 環境変数を設定する。
   2. ディレクトリーを INULIBDIR に変更する。
   3. deinstal 制御ファイルが現行ディレクトリーに存在する場合は、./lpp.deinstal スクリプトを実行する。 deinstal 制御ファイルが現行ディレクトリーに存在しない場合、 /usr/lib/instl/deinstal デフォルト・スクリプトを実行する。
3. ファイルセットに属するファイルをファイルシステムから削除します。
4. ヒストリー・データを除き、ファイルセット・エントリーを SWVPD から削除します。
5. ファイルセットに関するご使用条件の要件登録を活動停止させます。

deinstal 実行可能スクリプトは、最初のパラメーターが絶対パス名 である installp から、除去されるファイルセットのリスト (以下 で $FILESETLIST と呼ばれる) が入っているファイルに呼び出されます。

デフォルトの deinstal スクリプト内の流れを、以下に示します。

1. 入力ファイル $FILESETLIST にリストされている ファイルセットごとに、以下のことを行います。
2. Fileset.unconfig_d が存在する場合は、

   Fileset.unconfig_d を実行して、すべての構成変更、オブジェクト・データ・マネージャー (ODM) 変更、およびエラーとトレースのフォーマット変更を除去し、すべての更新および基本レベル・インストールのポストインストールおよびプリインストール・スクリプトで行われたすべての操作を元に戻します。 このファイルの使用は、お勧めしません。

3. Fileset.unconfig_d が存在しない場合は、
   1. そのファイルセットの各更新ごとに、以下を実行する。
      • すべての Fileset.unconfig_u スクリプトを実行して、 更新構成処理を元に戻す。
      • すべての Fileset.*.unodmadd と Fileset.unodmadd を実行して、更新の際に追加されたオブジェクト・データ・マネージャー (ODM) エントリーを削除する。
      • すべての Fileset.*.rodmadd および Fileset.rodmadd を実行して、更新の際に削除されたオブジェクト・データ・マネージャー (ODM) エントリーを追加する。
      • Fileset.undo.err が存在する 場合は、errupdate を実行して、エラー・ログ・テンプレートの変更を元に戻す。
      • Fileset.undo.trc が存在する場合は、trcupdate を実行して、トレース・レポート・テンプレートの変更を元に戻す。
      • Fileset.unpost_u を実行して、 ポストインストール・カスタマイズを元に戻す。
   2. ファイルセットの基本インストール・レベルに対して、 以下を実行します。
      • Fileset.*.unodmadd または Fileset.unodmadd (あるいはその両方) を実行して、インストールの際に追加されたオブジェクト・データ・マネージャー (ODM) エントリーを削除する。
      • Fileset.*.rodmadd または Fileset.rodmadd (あるいはその両方) を実行して、インストールの際に削除されたオブジェクト・データ・マネージャー (ODM) エントリーを追加する。
      • Fileset.undo.err が存在する 場合は、errupdate を実行して、エラー・ログ・テンプレートの変更を元に戻す。
      • Fileset.undo.trc が存在する場合は、trcupdate を実行して、トレース・レポート・テンプレートの変更を元に戻す。
      • Fileset.unconfig_i を実行して、 インストール構成処理を元に戻す。
      • Fileset.unpost_i を実行して、 ポストファイル・インストール・カスタマイズを元に戻す。
4. ファイルセットとともにインストールされたファイルおよびソフトウェア・データ情報を削除します。
5. Fileset.unconfig_d が存在しない場合は、
   1. そのファイルセットの各更新ごとに、Fileset.unpre_u を実行して、事前ファイル・インストール・カスタマイズを元に戻します。
   2. ファイルセットの基本インストール・レベルに対して、 Fileset.unpre_i を実行して、 事前インストール・カスタマイズを元に戻します。
6. ファイルセットに関連付けられた空のディレクトリーをすべて削除します。
   注: deinstal 実行可能スクリプトの実行中、 コールからエラーが戻された場合、そのエラーのログは取られますが、実行は継続します。 ファイルセットの実行は、一度エラーが検出されると通常取り消されることから、 これは、ほかのスクリプトとは異なります。 ただし、ファイルセットの削除が始まると、復旧方法はありません。 したがって、削除は、エラーが検出された場合のベスト・エフォートになります。

インストール状況ファイル

installp コマンドは、この status ファイルを 用いて該当する処理を判別します。 インストール・スクリプトを作成する場合、スクリプトは正しいフォーマット を持つ status ファイルを作成する必要があります。 status ファイルの各行のフォーマットを、以下に示します。

次の status ファイルの例では、installp コマンドに対して、bos.net パッケージの tcp.clientファイルセットおよび tcp.server ファイルセットのインストールが成功、nfs.client ファイルセットのインストールが不成功であったことを示します。

s bos.net.tcp.client
s bos.net.tcp.server
f bos.net.nfs.client

これらを使用する例については、デフォルト・インストール・スクリプト /usr/lib/instl/instal を参照してください。