これは標準的な質問パッケージ化されたソフトウェアを使用する場合と、自分でビルドしてインストールする場合について説明します。
自分でソースからビルドしてインストールするのではなく、OS ディストリビューションによって提供されるパッケージからソフトウェアをインストールする必要があるのはどのような場合ですか? ソースからビルドする方がよいのはどのような場合ですか?
答え1
特別な理由がない限り、ディストリビューションのパッケージを使用する必要があります。ディストリビューションのパッケージを使用すると、次のような重要な利点があります。
- パッケージをインストールおよびアンインストールし、最新の状態に保つ作業が少なくなります。
- パッケージング システムはソフトウェアの依存関係を自動的にインストールし、最新の状態に保ちます。
- セキュリティ アップデートはディストリビューションによって自動的に提供されるため、追跡したり、見逃すことを心配したりする必要はありません。
- パッケージ システムは、ディストリビューションの推奨方法で設定を行います。たとえば、apt ベースのシステムでは、Apache は /etc/apache2/*-enabled にシンボリック リンクと、それらを使用して Apache の機能を有効または無効にするツール (a2enconf、a2enmod など) とともにインストールされます。最初は習得に手間がかかるかもしれませんが、長い目で見れば、ディストリビューションのネイティブ ツールと方法を使用すると、作業が楽になり、設定がより適切に統合されます。
ディストリビューションで提供されているものよりも新しいバージョンのソフトウェアを使用する必要がある場合、またはコンパイル時に組み込む必要がある機能を有効にする必要がある場合は、コミュニティ リポジトリから、より新しいバージョンまたは機能豊富なバージョンのパッケージを見つけることができる場合があります。 レミのレポはよく知られた例で、RHEL/CentOS に同梱されているものよりはるかに新しいバージョンの PHP などを提供しています。コミュニティ リポジトリを使用すると、OS リポジトリの多くの利点を活用できますが、作成者がマルウェアをリリースし、それを完全な権限でシステムにインストールしてしまうリスクがあります。リスクとメリットの判断は、ケースバイケースで自分で行う必要があります。
どちらの方法もうまくいかない場合は、ソースからコンパイルする必要があります。ソースコードからソフトウェアをコンパイルする場合、推奨される方法は独自のバイナリパッケージを作成する独自のパッケージを構築すると、次のことが可能になります。
- 配布、インストール、依存関係の管理、レポート、アップグレード、ダウングレード、削除については、ディストリビューションのパッケージ管理システムを操作します。
- ビルド ツールと開発ライブラリを、すべてのテスト サーバーと運用サーバーにインストールするのではなく、単一のビルド ホストに制限します。
- 最初にテスト環境にパッケージを展開してから、同じパッケージを本番環境に展開するという一般的なリリース パスに従います。
それはパッケージのメンテナーであるあなた重大なバグやセキュリティ更新を見逃さないように、関連するセキュリティ メーリング リストに登録する必要があります。
ローカルで構築されたソフトウェアをパッケージ化せずにインストールする場合は、GNU ストウ整理された状態を保ち、クリーンにアンインストールしやすくなります。
答え2
アンドリューの反応が気に入りました。
Andrew の「よりよい統合」に関するコメントに付け加える具体的な点を指摘したいと思います。ソースからアプリケーション (将来のプロジェクトの依存関係) をインストールし、後でバイナリからパッケージ (deb または rpm パッケージなど) をインストールしようとすると、そのパッケージは依存関係がインストールされていることを認識しない可能性があります。最初の依存関係アプリケーションを RPM または DEB パッケージからインストールした場合、将来のパッケージはそれがインストールされていることを認識します。同じパッケージ メソッド (yum、pip、rpm など) を使用するのがベスト プラクティスです。ソースからのインストールは別の方法です。したがって、Andrew が言う容易さは真剣に検討すべき事項です。
「独自のバイナリ パッケージを作成する」には、インストール プロセスをログに記録できるという利点があることを付け加えておきます。ソース ファイルからインストールする場合は、ログに記録できるという利点はありません。