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

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

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

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

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

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

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

インストール手順の要件

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

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

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

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

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

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

パッケージ区分化の要件

ディスクレスまたはデータレスのクライアント・ワークステーションをサポートするために、パッケージのマシン固有の部分 (ルート部分) は、パッケージのマシン共有可能の部分 (ユーザー部分) と分けておく必要があります。 パッケージのusr部分には、'/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) のオブジェクト・クラスで構成されています。 SWVPDコマンドは、ユーザーがインストールされたソフトウェア製品を照会（lslpp）および検証（lppchk）するために提供される。 ODM オブジェクト・クラスは、維持管理されているソフトウェア・プロダクト情報の 配信範囲とフォーマットを定義します。

installpコマンドは、Object Data Managerを使用して、SWVPDデータベースに以下の情報を保持します：

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

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

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

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

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

/dev

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

/etc

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

/sbin

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

/var

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

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

/usr/bin

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

/usr/sbin

システム管理コマンド

/usr/include

インクルード・ファイル

/usr/lib

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

/opt

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

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

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

devices.BusTypeID.CardID.Extension

例えば、イーサネット・デバイスがPCIバスに接続され、コンフィギュレーション・マネージャによって一意のカード識別子1410bb02.このイーサネット・デバイスに関連するファイルセットのパッケージはdevices.pci.1410bb02という名前になる。 このパッケージ内にあるランタイム環境のファイルセット の名前は、devices.pci.1410bb02.rte です。

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

Product.msg.Language.SubProduct

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

例えばSuper_Widget製品にはplasticと入力して、以下を入力します。metalファイルセット・オプションのセット。 すべてSuper_Widget英語版USメッセージ・カタログは、次のような名前のファイルセットにまとめることができるSuper_Widget.msg.en_US.のために個別のメッセージカタログファイルセットが必要な場合は、以下のようにしますplasticおよびmetalオプションを使用すると、英語のUSメッセージカタログファイルセットの名前は次のようになります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 (in the usr part of the package)
/usr/sbin/sellhog
 (in the usr part of the package)

/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

必要な場合

*ifreq plum.tree (1.1.0.0) 1.1.2.3

*ifreq Fileset [(InstalledFilesetLevel)] RequiredFilesetLevel

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

1.1.2.3

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

1.2.0.0

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

1.1.3.0

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

:NONE.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.もしRequiredFilesetLevel4.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

   このindex.generate 3.1.0.0ファイルセットはindex.generateなぜなら3.1.0.0よりも新しいレベルである2.3.0.0レベルだ。
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

   このdatabase.rteファイルセットは1.2.0.0またはそれ以上でなければならないnew.fileset.rteファイルセットをインストールできる。 指定する場合は、database.rteおよびnew.fileset.rteが同じインストールセッションにインストールされると、インストールプログラムはdatabaseファイルセットの前にnew.fileset.rteファイルセット。

   このspreadsheet.rteファイルセットは1.3.1.0またはそれ以上new.fileset.rteファイルセットを正しく機能させる。 このspreadsheet.rteファイルセットをインストールする必要はありませんnew.fileset.rteファイルセットがインストールされます。ただし、同じインストー ル・セッションで両方がインストールされる場合に限ります。 適切なレベルのspreadsheet.rteファイルセットがインストー ルセッションの終了までにインストールされない場合、前提条件が満たされていないという警告メッ セージが表示されます。

   :NONE.wordprocessorA.rteファイルセットがインストールされている（またはnew.fileset.rteレベル4.1.0.0であるwordprocessorA.rteファイルセットのアップデートは4.1.1.1またはそれ以上。

   :NONE.wordprocessorB.rteファイルセットがインストールされている（またはnew.fileset.rteレベル4.1.1.0であるwordprocessorB.rteファイルセットのアップデートは4.1.1.1またはそれ以上。

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

   *instreq Super.Widget 2.1.0.0

   このSuper.msg.fr_FR.WidgetファイルセットはSuper.Widgetファイルセットがインストールされていない。 このSuper.msg.fr_FR.WidgetファイルセットはSuper.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ファイルのsizeセクションに'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.1同じファイルを配信し、同じレベルに適用されるからだ、farm.apps.hog 4.1.0.0.

更新日farm.apps.hog 4.1.1.2のいずれにも取って代わるものではない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.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をご覧くださいBad.Ideaファイルセット・レベルからのファイルセット・インストール・パッケージ6.5.6.0以降にはBad.Idea 6.5.6.0バリア・エントリー このような参入障壁があることでBad.Idea 6.5.4.0どのレベルでも満足できないBad.Idea以上6.5.6.0.

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

例としてYear.Full 19.91.0.0ファイルセットは、もはや1つのユニットとして配信されるのではなく、いくつかの小さな個々のファイルセットに分割されます。 小さなファイルセットのうちの1つだけ、おそらくはWinter 19.94.0.0の互換性エントリーを含むべきであるYear.Full 19.94.0.0.この互換性エントリーによりWinter 19.94.0.0に依存するファイルセットの必要条件を満たすファイルセットであるYear.Fullレベル19.94.0.0とそれ以前。

置き換え処理

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、「IY、「IX」で始まる修正キーワードは、オペレーティング・システム・メーカーが使用するために予約されている。

テクノロジー・レベルは、主要な更新レベルのフィックスです。 定期予防保守パッケージは、テクノロジー・レベルです。 テクノロジ・レベル識別子は、ソフトウェア製品名（パッケージ名ではない）で始まり、1つのドット（.）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.tcp.clientオプションのbos.netソフトウェア製品は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.unconfig Fileset.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 実行可能ファイルは、 デフォルトのインストール処理では行えない構成データの特定の操作もしくはマージを行うときに使用することができます。

ファイルセットにリストされている設定ファイル.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]]

次の例は、問題に対するFileset.fixdataスタンザを示していますMS21235.この問題の修正は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ファイルは、liblppliblpp.aファイルの'usrまたは'root部分で提供されなければならない。 ファイルセット.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 テキストで構成されます。 スタンザの名前は、システム上で検出された場合は除去される、ファイルまたはディレクトリーの 絶対パス名です。 スタンザ名はコロン (:)の後に改行文字が続く。 属性がスタンザ名の後に続く場合、属性は以下のような形式になります。=価値がある。 属性は、除去の必要があるハードリンクおよびシンボリック・リンクの識別に使用します。 各属性の説明は、別の行で行われます。 次のリストでは、示されているファイルに関連付けられた有効な属性を説明します。

例えば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ファイルはもはや存在せずst.petersburgファイルをRussia.libファイルセット。

この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)までのファイルには、製品パッケージのバックアップフォーマットファイルイメージが含まれています1Nを通して。
• プロダクト・パッケージのイメージ・ファイルは、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 バイト・ブロック境界から始まる。
• 最初に目次ファイルを書き出す。 このファイルの最後のセクタをヌル文字 (x'00').目次ファイルの終わりを示すには、少なくとも1つのヌル文字が必要です。 したがって、全部 null 文字のセクターが必要な場合があります。
• 目次ファイルの次に、プロダクト・パッケージのイメージ・ファイル のそれぞれを、連続したセクターに書き出す。 各ファイルの最後のセクターに、null 文字を埋め込みます。 ファイルがブロック境界で終わる場合、null 文字は不要です。
• セット内の各ディスケットのブロック 0 に、ボリューム ID セクターが入る。 このセクターのフォーマットを、以下に示します。

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

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

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

MonthDayHourMinuteSecondYear

Hour は 00 から 23 の値でなければなりません。 すべての日付と時刻のフィールドには 2 桁の数字が入ります。 したがって、Monthは次のように表される03以前の表示は次のようになっていました。3と表し、Yearは次のように表す94以前の表示は次のようになっていました。1994.

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

位置のフォーマットは 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アーカイブ・ライブラリー・ファイルから パッケージ・ディレクトリー (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は、/lpp/Package_Nameを使用するroot部分を除き、パッケージ・ディレクトリーと同じです。

9. これが、ファイルセット更新パッケージではなくインストール・パッケ ージならば、/usr/lib/instl/rminstal スクリプトを実行して 、インストールされるファイルセットごとに以下のことを行います。
   注：特に指定がない限り、存在チェックされたファイルはliblpp.aコントロール・ファイル・ライブラリからリストアされたものでなければならない。
   1. Fileset.pre_rm が存在する場合は、 Fileset.pre_rm を実行して、このバージョンまたは Filesetの既存のバージョンからファイルを除去する前に、必要なステップを実行してください。
   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 ファイルにリストされたファイルセットごとに、以下のことを行います。
   注：どのステップでも失敗はステータス・ファイルに記録され、そのファイルセットの処理は終了する
   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データベースにtrusted computing base tcb_enabled属性が設定されている場合は、 tcbckコマンドを呼び出して、システムにtrusted computing base情報を追加します。
   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
   • ファイルセット。 al
   • ファイルセット。 inventory
   • ファイルセット。 pre_d
   • ファイルセット。 アンプレ
   • ファイルセット。 unpre_u
   • ファイルセット。 未投稿
   • ファイルセット。 アンポスト・ユー
   • ファイルセット。 アンオッドマッド
   • ファイルセット。 unconfig
   • ファイルセット。 アンコンフィグ
   • $SAVEDIR/Fileset. *.rodmadd
   • SAVEDIR/Fileset. *.unodmadd

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

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

1. リジェクトの場合は、必要条件を検査して、従属プロダクト更新もすべてリジェクトされることを確認します。
2. プロダクト・パッケージの各部分 (例えば、usr および root) ごとに、
   1. INUTREEを設定する（Uは usr、Mは root。） と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が存在する場合にInvoketrcupdateを実行します。
   6. Fileset.undo.errが存在する場合は、errupdateを呼び出して、インストール中に行ったエラー形式テンプレートの変更を元に戻します。
   7. /usr/lib/objrepos/PdAt ODM データベースに、Fileset.tcb ファイルが存在し、トラステッド・コンピューティング・ベース属性 tcb_enabled が設定されている場合は、tcbck を呼び出して、システムへのトラステッド・コンピューティング・ベース情報を削除する。
   8. ソフトウェア情報データベースへの変更を取り消すには Fileset、 sysck.inventory が存在する場合に呼び出します。
   9. インストールの際に行われた post_installation 処理があれば、元に戻す。

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

   10. Fileset.al ファイルからマスター・アプライ・リスト (master.alという ) を作成します。
   11. Fileset を $FILESETLIST.new に 追加する。
2. $INUTEMPDIR/master.al が存在する場合は、以下のことを行います。
   1. ディレクトリを '/(ルート) に変更する。
   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 を参照してください。