2013/08/14 修正
dev.haiku-os.org/wiki より、Migration to Package Management の私訳です。訳のおかしいところは、原文を参照ください。

Package Management への移行

エンドユーザーにとっての変化

• ほぼすべてのソフトウェアはパッケージ中に存在し、仮想的にのみ展開されます。仮想的に展開されたパッケージの内容は読み取り専用となります。
• ソフトウェア (つまりパッケージ) は、コマンドラインのパッケージマネージャー、pkgman を通じてインストールできます。-- pkgman search/install/uninstall/update ... それぞれ、パッケージを検索、インストール、アンインストール、アップデートします。また、パッケージを "/boot/system"、"/boot/common"、"/boot/home/config" 内の、"packages" サブディレクトリへ移動 (コピーではない) することで、手動インストールできます。
• ディレクトリレイアウトは変更され、多くのディレクトリが読み取り専用になっています。詳しくは、DirectoryStructure を参照ください。
• Deskbar メニューは異なる動作をします。それは新しい仮想ディレクトリ、Tracker/Deskbar 機能を使ってその内容を生成します。すべてのパッケージは、それぞれのシンボリックリンクを "data/deskbar/menu" に置くことにより Deskbar メニュー項目に提供します。仮想ディレクトリは、すべてのインストール場所の個々のディレクトリと、併せてユーザー設定ディレクトリ "/boot/home/config/settings/deskbar/menu" をマージします。それはつまり、パッケージがインストール / 削除されたときは、すぐに Deskbar メニュー項目が自動で追加 / 削除されることを意味します。ユーザー設定ディレクトリにより、手動で新規項目を追加できます。デフォルトの仮想ディレクトリを変更することで、全体の動作を変更できます。デフォルトの仮想ディレクトリ、"/boot/system/data/deskbar/menu_entries" を使う前に、Deskbar は最初に "/boot/home/config/settings/deskbar/menu_entries" を調べます。これは、仮想ディレクトリでも、あるいは、普通のディレクトリ、どちらかへのシンボリックリンクでも同様です。たとえば、それを "menu" ディレクトリへのリンクにすると、Deskbar がそのディレクトリの内容だけを使うようになります。すなわち、メニューの内容は完全にユーザー定義になります。
• 同様に、MIME タイプの管理もこれから少し変化します。デフォルトの MIME タイプ用のデータベース項目は、システムパッケージに含まれ、アプリケーションの MIME タイプ用については、個々のアプリケーションを含むパッケージに含まれます。そのため、どちらも削除されません。しかし、FileTypes プレファレンスでそれらを編集すると、それらは上書きされてしまいます。現在、まだいくつかの既知のバグや足りない機能があります。-- たとえば、アプリケーション MIME タイプは、パッケージをインストール / 削除しても、自動で追加 / 削除されません。そして、FileTypes の MIME タイプ削除機能は書きなおす必要があります。

アプリケーションデベロッパーにとっての変化

• すべての開発用ファイル (ヘッダー、ライブラリ、ツールチェーン) は、個々のインストール場所の "develop" へ移動しました。ヘッダーは "develop/headers" 中に、開発用ライブラリは "develop/lib" 中に有ります。開発用ライブラリとは、静的ライブラリに加えて、共有ライブラリへのシンボリックリンクも指します。共有ライブラリ自体、およびライブラリを使ってプログラムを動作させるために必要なすべてのシンボリックリンク (せいぜいライブラリにつきひとつのリンク -- soname) は、"lib" 中に有ります。
• ハイブリッドビルド Haiku の副アーキテクチャ用コマンド、ライブラリ、アドオン、そしてヘッダーはそれらの通常の位置の "<arch>" サブディレクトリ内にあります。これは、主アーキテクチャの所のみにあるシステムヘッダーを含みません。
• setgcc は無くなりました。副アーキテクチャ用ツールチェーンのコマンドは、"/boot/common/bin/<arch>" にあります。そのパスを環境変数 PATH に追加すると、それぞれの主アーキテクチャのコマンドを隠すでしょう。-- この効果は、setgcc が起こしたものと似ているでしょうが、それは、現在のシェルのセッションだけに対するものです。副アーキテクチャのツールチェーンコマンドはまた、標準パスに "-<arch>" を追加した名称で利用できます (例. gcc2/gcc4 ハイブリッドでは、gcc4 実行形式に "gcc-x86" の名称)。
• ソフトウェアはパッケージツールを使ってパッケージ化できます。詳しくは、BuildingPackages を参照ください。

Haiku デベロッパーにとっての変化

• ハイブリッドビルドは、2 つの異なる generated ディレクトリをもう必要としません。その代わりに、ビルドは両方のコンパイラで設定され、すべての出力ファイルはひとつの generated ディレクトリに配置されます。
• パッケージアーキテクチャの考え方が導入されました。それはほとんどアーキテクチャと同じ意味です。ただし、"x86_gcc2" が x86 gcc 2 を参照し、"x86" が x86 gcc 4を参照する、x86 は除きます。
• いくつかの configure スクリプトオプションが変更されました。
  • --build-cross-tools と --build-cross-tools-gcc4 はマージされました。(パッケージ) アーキテクチャは常に指定する必要があります。
  • --build-cross-tools および --cross-tools-prefix はハイブリッドビルドを指定するため、何回でも与えられます。最初の --build-cross-tools だけは、ビルドツールへのパスを与える必要があります。
  • 新しいオプション、--target-arch が導入されました。これは、Haiku上でネイティブコンパイラでビルドするために使用するものです。デフォルトでは、--build-cross-tools と --cross-tools-prefix のどちらも指定されない場合、ビルドは、ホストのシステムに合う (ハイブリッド) 構成に設定されます (たとえば、gcc2/gcc4 ハイブリット上では、ビルドは同様にその構成で設定され、純粋な gcc4 Haiku 上では、gcc4 ビルドを得るでしょう)。--target-arch は、ビルド用のアーキテクチャを指定することで、デフォルトを上書きします。オプションは、ハイブリッド構成を指定するために複数与えることができます。たとえば、"--target-arch x86_gcc2 --target-arch x86" は、gcc2/gcc4 ハイブリッドを指定し、gcc2/gcc4 または gcc4/gcc2 Haiku 上で使用できます。
  • 新しいオプション、--use-xattr-ref は、拡張属性が使えるが、サイズ制限で --use-xattr が使えない場合 (たとえば、ext4)、使用出来ます。ビルドシステムは、別れたファイルを用いて標準の属性エミュレーションの少し異なるバージョンを使うでしょう。それは、ユニーク ID による属性付きファイルのタグ付けを含んでいます。従って、ファイルの inode ID が変化した場合、または属性付きファイルがそれらの属性ファイルを削除することなく削除された場合でも、属性や異なるファイルの混合は一切起こりません。
• gcc 2 ビルド構成は、これからは 64 bit システム上 (32 bit 環境なしでも) でも動作するはずです。いまのところ、openSUSE 12.3 でしかテストされていませんが、ほかの Linux ディストロ上や Unix でも動作するはずです。そのため、--use-32bit は不適切なものとなるはずです。
• build/jam は、特に、Haiku イメージと、(オプショナル) パッケージについていくつか再編成されました。
  • ビルドされるほとんどのものが最後に "haiku.hpkg" と "haiku_devel.hpkg" パッケージ (または副アーキテクチャ用の、"haiku_<arch>.hpkg"、"haiku_<arch>_devel.hpkg" パッケージ) へ入ります。パッケージの内容は、"packages" サブディレクトリ中の個別のファイルで定義されています。
  • Haiku イメージファイルの内容を定義するファイルは、これからは"images" サブディレクトリにあります。
  • "repositories" サブディレクトリは、外部のリポジトリを定義します。通常のビルドに最適なものは、HaikuPorts リポジトリです。それぞれのアーキテクチャに対して、リポジトリの内容を定義したファイルがあります。そのファイルの変更には、リポジトリの個々のバージョンをビルドする必要があります。現在それは、haiku-files.org サーバー上で手動で行う必要があります。プロセスはまもなく自動化されるでしょう。
  • ReleaseBuildProfiles はこれから DefaultBuildProfiles となります。
• オプショナルパッケージはほとんど無くなりました。ほんの数個のメタオプショナルパッケージだけが残っています。正規のパッケージの追加は、AddHaikuImagePackages ルールを用いて行なわれます。引数は、バージョンを除いたパッケージの名称 (すべて小文字) です。
• アーキテクチャに依存し、かつ主アーキテクチャのみに関連しないすべてのビルド変数は、添字 "_<arch>" 付きにリネームされました (たとえば、TARGET_GCC_<arch>、TARGET_DEFINES_<arch> など)。変数は、ほとんどの場合ルールの実装のみに使われます。従って、これは Jamfiles 上には大きな影響は与えません。
• 新しいビルド変数 HAIKU_PACKAGING_ARCHS および TARGET_PACKAGING_ARCH[S] があります。複数形バージョンは、構成されたアーキテクチャのリストに設定されます。例、gcc2/gcc4 hybrid では、"x86_gcc2 x86" です。TARGET_PACKAGING_ARCH は現在のアーキテクチャに設定されます。通常、それは、主アーキテクチャを指します。場合によっては、(ほとんどの場合ライブラリのためですが) ターゲットは全アーキテクチャに対してビルドされる必要があります。それは、TARGET_PACKAGING_ARCH (および他の変数) を、ループ内で処理されるアーキテクチャに従って設定するループで処理されます。​短いサンプルとして、src/kits/textencoding/Jamfile を参照してください。
• Build features ("build/jam/BuildFeatures" で定義されている) はこれからは少し異なる動作をします。ビルド変数の代わりに、build features を処理する専用のルール (FIsBuildFeatureEnabled、UseBuildFeatureHeaders、BuildFeatureAttribute) があります。​例として、src/add-ons/mail_daemon/inbound_protocols/pop3/Jamfile を参照ください。
• "update" ビルドプロファイルの動作は、いくらか変更されます。なぜなら、パッケージのために、2 つのコンテナレベル、イメージ と パッケージを持つからです。jam -q @alpha-raw update libbe.so は、まず haiku.hpkg パッケージ中の libbe.so をアップデートしてから、イメージ中の haiku.hpkg をアップデートします。jam -q @alpha-raw update haiku.hpkg は、イメージ中の "haiku.hpkg" をアップデートしますが、"haiku.hpkg" はリビルドされません。アップデートが必要なら、最初に明確にリビルドする必要があります。-- jam -q haiku.hpkg を使って。これはなお問題になることがあるかもしれません。なぜなら、どの optional build features が有効になるかは指定されたビルドプロファイルによるからです。
• 新しいビルドプロファイル、"update-packages" があります。それは、すべてのパッケージをアップデートし、次にイメージ内のすべてのパッケージ (ダウンロードしたものも含む) をアップデートします。それは簡易なシステムアップデートです。それは、潜在的に同じ名前のパッケージを置き換えながら、単にパッケージをイメージにコピーするだけなので、名前が違う古いパッケージは削除されません。システムはどのパッケージが有効かを覚えているため、"/boot/{system,common}/packages" ディレクトリを最初に空にしておくことが (また、"administrative" サブディレクトリを削除しておくことも) 推奨されます。

ソフトウェア移植者にとっての変化

• レシピ (以前の bep) ファイルは変更されました。多くのレシピがまだアップデートされていません。haikuporter も同様に大きく変わっています。詳しくは、​haikuporter のドキュメントを参照してください。