DebianをJessieからStretshにアップグレードした後、ソースから以前にビルドしたツールを再コンパイル/再ビルドする必要があるかどうか疑問に思います。
私の主なツールは次のとおりです。
- Omnet++ネットワークシミュレータ(Eclipseベース)
- 相撲交通シミュレータ
- Pythonで書かれた様々なプログラム
- Rの以前のバージョン(2-11)
私のツールはすべて壊れて再構築する必要があると思いましたが、そのうちのいくつか(Omnet ++、Sumo)を使ってみると正しく動作しているようですが、どれくらい一貫性があるかはわかりません。
もしそうなら、それがうまくいけば、一貫していない方法で動作する可能性はありますか?
答え1
これは、ツールが使用するライブラリ、Stretchに新しいバージョンがあるかどうか、これらの新しいバージョンのABIが以前のバージョンと互換性があるかどうかによって異なります。これは、プログラム内の特定の機能にのみ問題がある可能性があることを意味します。
私はあなたのツールについて知りませんが、一般的に安全なアプローチはすべてを再コンパイルすることです。
答え2
動作するかどうかは、これらのツールが何に依存しているか(そして新しいオペレーティングシステムで依存しているものが見つかるかどうか)によって異なります。
しかし、まだDebianベースのオペレーティングシステムを使用しているので、問題なく動作し続けます。
答え3
カスタムコンパイルされたプログラムがアップグレードされたオペレーティングシステムで起動すると、これは必要な動的ライブラリが見つかり、その点で正しく機能することを意味します。 (他の非互換性のためにまだ失敗する可能性がありますが、再コンパイルは役に立ちません。)しかし、新しいOSの一部ではない古いパッケージで動的ライブラリを見つけることができますが、新しいOSの自動削除中には検出されません。アップグレード。したがって、後でこれらの古いパッケージを削除すると(パッケージ管理フロントエンドは通常、どのような方法でもそのパッケージを強調表示します)、カスタムコンパイラがクラッシュします。 (ただし、カスタムパッケージを介してインストールし、現在使用されていないライブラリパッケージに依存している場合は、パッケージマネージャが警告を表示します。)このツールを使用して動的ライブラリの依存関係を検索し、ステータス検索を使用してそのパッケージをldd
検索できます。dpkg -S
通過しますapt-cache policy
。
古いパッケージを長期間使用すると、セキュリティ更新プログラムが届かないため、セキュリティ上のリスクが発生します。適切なLTSリポジトリを有効にすると、通常は一定期間に役立ちます。特に、Xercesはこの分野でコード品質についてあまり良い評判を得ていませんでした。