独自のソフトウェア再パッケージ

Matlabのインストールに含まれているのと同じバージョンであると仮定すると、削除が問題になり、リンクに置き換える理由を理解できません。しかし、なぜか自分のために多くのことをしているような感じがします。

私がMatlabのようないくつかのバージョンの独自のソフトウェアパッケージを維持するグループをサポートしたとき、私たちのグループはそのパッケージを別のディレクトリにインストールし、次のものを使用しました。modulesユーザーがこれらのパッケージを使用できるようにユーザーエクスペリエンスを切り替えたい場合は、ユーザーエクスペリエンス管理を維持します。

次のタイトルのU&L Q&Aをご覧ください。同じ親ディレクトリの下に複数の子ディレクトリをPATHに追加するここでは、$PATHシステム環境変数を管理するためのさまざまな戦略について説明します。これと同じ戦略は、ほぼすべての環境変数にも適用できます。これは、独自のアプリケーションの機能を制御する要素であることがよくあります。

私努力する私がインストールしているAURでPHP App Engineパッケージを維持するには、/optそこにスタンドアロンのMatlabパッケージ（たとえば/opt/matlab）を入れて、実行可能ファイルを再シンボリックリンクし、/usr/bin他のものを再リンクする必要があります/usr/share/applications。

私はアーチ用のバイナリを再パッケージする別のパッケージを見てみましょう。絵ドロップボックスまたはGoogle Chromeバッグ。 Chromeパッケージは特にDebianバイナリに依存しているため、アーチにインストールするとDebianの詳細が削除されます。

一方、/opt/matlab共通ライブラリとJREを削除する代わりに、すべてをそのままにしておくと、依存関係が変更されるたびに中断されないか、再テストして再パッケージする必要がある動作するMatlab依存関係を持つ可能性が高くなります。 。

MatlabフルパッケージとMatlab最小パッケージの2つのバージョンを提供できます。

大規模なアプリケーションには、2つの理由でバンドルライブラリが付属しています。 1つの理由は、ユーザーがすべてのライブラリを追跡したり、ディストリビューションにライブラリを含むパッケージを見つけたり、正しいバージョンがあるかどうかを確認したりする必要がないためです。ディストリビューションは時間の経過とともに特定の時点で異なるライブラリバージョンを提供することが多いため、すべてのディストリビューションで動作するバイナリパッケージを維持するのは難しいです。パッケージが特定のディストリビューションの特定のバージョンで動作する場合、ディストリビューションのバージョンに依存することは問題ではありません。ただし、Arch Linux には安定したリリースがないため、最小限に急速に変化するライブラリをバンドルしない場合は、パッケージを頻繁に更新する必要があります。

ライブラリをバンドルするもう一つの理由は、プログラムが特定のライブラリバージョンに依存することがあるからです。原則として、ライブラリには2つの部分バージョン番号があります。 ABIが互換性のない方法で変更されるたびに変更されるメジャーバージョン番号と、変更（バグ修正や互換性のない新機能）が変更されるたびに変更されるマイナーバージョン番号。変更されました。以前のバージョンとの互換性が壊れています）。 （多くのライブラリにはMAJOR.MINOR形式のバージョン番号がありますが、これは普遍的なものではありません。）メジャーバージョンが異なるライブラリバイナリは異なります。ソネーム、一緒にインストールすることができますが、マイナーバージョンのみが異なるライブラリバイナリは同じsonameを持つため、ダイナミックリンクには1つしかありません。プログラムがバージョン 1.2 に対して構築されテストされたが、バージョン 1.3 がある場合、プログラムはしなければならないまだ働いています。ただし、時にはプログラムはABIの一部ではなく、1.3で破損する可能性がある文書化されていないインターフェイスを使用します。すべての可能なライブラリバージョンの組み合わせでテストすることはサポートにとって悪夢になるため、バイナリディストリビュータはすべてのユーザーが同じライブラリバージョンを使用することを好みます（一部のシステムライブラリ、特にlibcを除く）。

1アプリケーション_{バイナリインタフェース：コンパイルされたライブラリとコンパイルされたプログラム間のインタフェース仕様。}