Translations:Binary package guide/4/ja


 * 1) まず第一に、それは、管理者が更新された同様のシステムを維持することができます.  ソースからすべてをコンパイルするために持つことは時間の浪費になることができます.  唯一のシステムは、ソースからすべてをコンパイルする必要があり、他のシステムにはバイナリパッケージを再利用する場合、いくつかの同様のシステムを維持し、おそらくそれらのいくつかは、古いハードウェアで、はるかに容易にすることができます.
 * 2) 第二の理由は、安全な更新を行うことです.  ミッションクリティカルなシステムのためには、可能な限り使用可能な滞在することが重要です.  これは、それ自体に最初にすべての更新を行い、ステージングサーバーで行うことができます.  ステージングサーバは良好な状態になると更新が次に重要なシステムに適用することができます.  このアプローチの変形は、同じシステム上のchroot環境で更新を行うと、実際のシステムであっ作成したバイナリを使用することです.
 * 3) 第三の理由は、 バックアップの通りです.  多くの場合、バイナリパッケージが壊れたシステム（すなわち、壊れたコンパイラ）を回復する唯一の方法です.  いずれかの周りにプリコンパイルされたバイナリバイナリパッケージサーバ上またはローカルを持つことは、壊れたツールチェーンの場合には大きな助けとすることができます.
 * 4) 最後に、それはまた、 非常に古いシステムの更新をサポートしています.  非常に古いシステムを更新する作業が大幅にバイナリパッケージを使用して緩和することができます.  これらはビルド時の依存関係を更新/インストールする必要はありませんので、古いシステム上でバイナリパッケージをインストールするには、通常は便利です.  彼らは事前にコンパイルされているので、バイナリパッケージもビルドプロセスの失敗を回避します.