元のパッケージ内の誤り、時間の経過に伴う製品またはその使用法の変更、あるいは周辺のソフトウェア環境の変更のために、ソフトウェアコンポーネントの望ましい構成が変わることがあります。パッケージ名の変更のみが必要な場合もあります。そのような変更を計画する場合、アップグレードを行うユーザーは、意図しない副作用が絶対に発生しないように検討してください。
pkg update への考慮事項がますます多様化しているため、このセクションでは、3 種類のパッケージ再編成について説明します。
単一パッケージの名前変更
2 つのパッケージのマージ
パッケージの分割
単一パッケージの名前変更は簡単です。IPS には、パッケージの名前が変更されたことを知らせるメカニズムが備わっています。
パッケージの名前を変更するには、次の 2 つのアクションが含まれており、内容を持たない既存のパッケージの新しいバージョンを発行します。
次の書式による set アクション:
set name=pkg.renamed value=true
新しいパッケージへの require 依存関係。
depend fmri=pkg:/newpkgname@version type=require
名前変更されたパッケージは、depend または set アクション以外の内容を配布できません。
新しいパッケージでは、それを名前変更前の元のパッケージと同時にインストールできないようにする必要があります。どちらのパッケージも同じ結合依存関係の対象となっている場合は、この制約が自動的に適用されます。そうでない場合は、新しいパッケージには、名前変更されたバージョンに古いパッケージへの optional 依存関係が含まれている必要があります。これにより、ソルバーが両方のパッケージを選択して競合チェックが失敗することがなくなります。
この名前変更されたパッケージをインストールするユーザーはその名前変更された新しいパッケージを自動的に受け取ります。これは、それが古いバージョンの依存関係であるからです。名前変更されたパッケージが他のどのパッケージからも依存されていない場合、それは自動的にシステムから削除されます。古いソフトウェアが存在していると、名前変更されたいくつかのパッケージがインストール済みとして示されることがあります。その古いソフトウェアが削除されると、名前変更されたパッケージも自動的に削除されます。
パッケージの名前変更は何度行なっても問題はありませんが、ユーザーに紛らわしいことがあるため推奨されていません。
パッケージのマージも簡単です。次の 2 つの事例は、パッケージをマージする例です。
あるパッケージが名前変更バージョンで別のパッケージを取り込みます。
パッケージ A@2 がパッケージ B@3 を取り込む必要があるとします。これを行うには、パッケージ B の名前をパッケージ A@2 に変更します。前述のように両方のパッケージをまとめて更新できるように結合される場合を除き、B@3 への optional 依存関係を A@2 に忘れずに含めてください。A が B を取り込んだので、B を B@3 にアップグレードするユーザーは A をインストールするようになります。
2 つのパッケージが同じ新しいパッケージ名に名前変更されます。
この場合は、両方のパッケージの名前をマージされた新しいパッケージの名前に変更して、それらにほかの制約がなければ、古いパッケージへの 2 つの optional 依存関係を新しいパッケージに含めます。
パッケージを分割する場合は、単一パッケージの名前変更に説明しているように、結果となるそれぞれの新しいパッケージの名前を変更します。結果となる新しいパッケージのいずれか 1 つを名前変更しない場合、そのパッケージの分割前と分割後のバージョンは互換性がなくなり、エンドユーザーがそのパッケージの更新を試みると、依存関係ロジックに違反する可能性があります。
元のパッケージの名前を変更し、分割によって作成されたすべての新しいパッケージへの require 依存関係を含めます。これにより、元のパッケージへの依存関係を持ったパッケージは、新しい内容をすべて入手します。
分割されたパッケージの一部のコンポーネントは、マージとして既存のパッケージに取り込むことができます。アプリケーションが共有領域を使用できるようにする方法を参照してください。