複数のパッケージ マネージャーを使用することの落とし穴はありますか? Redhat の yum と Debian の aptitude を同時に使用できますか?
この記事とこのインフォグラフィック
に出会いました-
私は Debian を選択する傾向がありましたが、VM を簡単にインストールしたところ、安定版レポではまだカーネルが 3.2 にアップグレードされていないことがわかりました。そのため、Archlinux に移行する予定ですが、インフォグラフィックではパッケージの入手可能性が低く評価されており、Fedora または Ubuntu リポジトリから .deb または .rpm ファイルをインストールできるかどうか疑問に思っていました。
簡単に言えば、はい、できますが、実際にはすべきではありません。
以下は、クロスディストリビューションのインストール時に考慮すべき事項のリストです (順不同)。
そもそも yum/apt/yast のようなものが存在する主な理由は、いわゆる依存地獄を避けるためです。他のシステムのパッケージを使用することで、パッケージに投入された作業がクリーン インストールから失われます。
セカンダリ パッケージ マネージャーは、独自の依存関係を満たし、既にインストールされているものを多数インストールする必要があります。これは、パッケージを一度に 1 つずつインストールする必要があることを意味します。これにより、プライマリ パッケージ マネージャーから既にインストールされているパッケージを上書きしたり、あらゆる種類の問題を抱えたりすることがなくなります。
その場合、完全にインストールすることさえできるかもしれませんが、依存関係の問題やパッケージの競合が発生する可能性があります. そうでない場合は、さまざまなツールを使用してパッケージを抽出し、バイナリ ファイルをファイル システムに置くことができます (エイリアンを参照するか、.rpm および .deb ファイルの抽出に関するこの記事を参照してください)。
これにより、システム上のファイルが取得されますが、そのままで動作するという保証はありません。いくつかの追加の手動ハンティングが必要になる場合があります (通常は必要です)。
その場合、問題が発生する可能性は低くなります。2 つのディストリビューションの基本パッケージの違いが大きいほど、バージョンが異なり、ファイル名がバイナリと一致しないため、実行しているディストリビューションでは利用できない共有ライブラリが不足している可能性が高くなります。探している。
技術的には、他のディストリビューションから基本的な依存関係を抽出してファイルシステムに配置することもできますが、ソースからコンパイルする必要がある場合は、確かに苦労します。gcc がどれほど混乱するか想像してみてください。
これを明確に説明できる最善の方法は、Web ホストから VM を購入する際に最近見られる一般的な問題です。独自のブランドの xen または virtuozzo カーネルを取得すると、netfilter がカーネルに含まれており、ABI が変更されているため、iptables は完全には機能しません。再び動作させるのはかなりの頭痛の種になる可能性があり、この問題は iptables に限定されません。ここでの私の最善のアドバイスは、必要なカーネルが独自のベース リポジトリにあるディストリビューションを選択することです。
他のシステムからのパッケージが欲しくなった場合は、間違いなくこれを行う必要があります。さまざまなディストリビューションでビルド環境の設定が異なるため、パスやその他の構成の問題を理解するのに半分の時間を費やすことになります。