フォローアップUbuntu LTS バイナリは Debian と互換性がありますか?
Ubuntu と Debian のバイナリ パッケージは互換性がないことが多いことは知っています。異なるソースからのパッケージを混ぜるのは一般的に悪い考えであり、人々はいつもそうしないように警告されています。ですから、議論は純粋に技術的なものにしておきましょう。
もちろん依存関係が問題ではないのに、異なるソースからのパッケージに非互換性をもたらすのは正確には何でしょうか?
------ 分離、詳細は下記 ------
のように言葉:
バイナリ互換性について（https://wiki.ubuntu.com/MarkShuttleworth#What_about_binary_compatibility_between_distributions.3F): Debianパッケージは異なるツールチェーンバージョンで構築されている可能性が高いため、問題が発生する可能性があります。
ツールチェーンのバージョンが異なるとなぜ問題が発生するのでしょうか？
- 私はDebian sidから最小限のパッケージセットをDebian stableにプルする方法を知っており、これまでずっとそうしてきました。
- 私はUbuntu / Debianの古いバージョンから新しいバージョンにパッケージを移行したり、
- Ubuntu / DebianからRedHatやFreeBSDなどの別のディストリビューションに実行ファイルを1つコピーする
そして一度もない以前も問題がありました。では、人々が言っている問題の原因は一体何なのでしょうか?
それは gcc またはカーネル バージョンですか? おそらくそうではないと思います。そのリリースを使用している間は常にアップグレードされているからです。
それで、それは glibc のバージョンですか? しかし、通常は下位互換性があり、おそらくそうですよね?
最初のリンクからの回答を引用します:
相互互換性の保証や暗示はまったくありません。何か問題が起きても、Debian や Ubuntu のコミュニティが同情してくれることは期待できません。その場合、ほとんどは自分で対処するしかありません。それで構わないのであれば、ぜひ試してみてください。
つまり、この行為に対する警告はどこでも見かけますが、それ以上の技術的な説明をする人はいません。誰か、この行為のリスク、潜在的な技術的問題を列挙してもらえませんか?
この回答は、Debian や Ubuntu などの異なるソースからのパッケージを混在させたい場合や、同じディストリビューション内でリリースが異なるパッケージを混在させたい場合 (依存関係が問題にならない場合)、最も安全なアプローチを選択して、Debian には決して含まれないとわかっている PPA を、現在使用している Debian Bullseye に取り込むのに役立ちます。
答え1
バイナリとパッケージの非互換性は異なるため、別々に説明する価値があります。
バイナリ非互換性
これは通常、ツールチェーンの違いなどについて話すときに参照されるものです。ツールチェーンツールチェーンはカーネルと並んで、開発者が最も後方互換性の維持に注意を払っている領域の一つであるため、非互換性自体は珍しい。その結果、過去にビルドされたバイナリは、その互換性が維持されている限り、引き続き実行されるはずである。バイナリ依存関係は引き続き利用可能であり、それは必要なライブラリを維持することに帰着します。
互換性が失われるのは、前方互換性のときです。「将来」にビルドされたバイナリが確実に動作するとは限りません。これは通常、Cライブラリのシンボルが欠落しているという形で現れます（これは、Cライブラリの開発者が互換性の維持に細心の注意を払っているために検出されます）。Cライブラリはあまり変更されないので、異なるCライブラリでプログラムを構築しても必要なシンボルは変更されず、互換性が維持されるはずだと考える人もいるかもしれません。しかし、そうではありません。関数は後方互換性のない方法で定期的に変更されます。Cライブラリは、後ろ向き以前のインターフェースと互換性のある関数のバージョンを適切なバージョン シンボルで引き続き提供することにより、互換性を維持します。たとえば、GNU C ライブラリのバージョン 2.33 では、ファミリstat( fstat/ lstat/statなど) などの一般的な関数に互換性のない変更が加えられています。これらの関数を使用する 2.33 のデフォルト設定でビルドされたプログラムを実行するには、C ライブラリのバージョン 2.33 が必要になります。
ツールチェーン関連のライブラリと C ライブラリは、このような非互換性がライブラリ シンボルの変更または soname の変更として表示されるように維持され、パッケージ依存関係にエンコードされるか (パッケージ化されたソフトウェアの場合)、動的リンカーによってキャッチされます (個別のバイナリの場合)。
C ライブラリほど注意深く保守されていないライブラリでは、このような非互換性はすぐには現れず、問題のある組み合わせがテストされた場合にのみ現れます (そして、その場合でも、おそらく特定の状況でのみ現れます)。ディストリビューションの開発者は通常、開発中のリリースのコンテキストでのみパッケージをテストするため、Ubuntu 20.04 用に作成したパッケージが Debian 10 に正しくインストールされても、6 月 21 日の午前 1 時から午前 2 時 (中央ヨーロッパ夏時間) の間に使用するとペットのリスが死んでしまうことはわかりません。
これはうまく次のことにつながります...
パッケージの非互換性
意識的であるかどうかに関わらず、パッケージが単独で構築されることはめったになく、ディストリビューション リリースの一部です。これはパッケージ ソース (より一般的にはプロジェクト ソース) 自体から始まります。プロジェクトとパッケージは開発者のシステム上に構築されるため、多大な労力を費やさない限り、依存関係が正確にエンコードされない可能性があります。
これはバイナリパッケージの依存関係やドキュメントに記載されている依存関係にまで及びます。プロジェクトのメンテナーは、現在の構成でプロジェクトが機能するのは、たとえばsystemdバージョン239が特定の方法でシステムの設定を開始したためだと気付かないかもしれません。パッケージのメンテナーも、作業中のディストリビューションのリリースにsystemdのバージョン239が既に含まれていた場合、それに気付かないかもしれません（ディストリビューションのメンテナーは通常、未来に生きていることを覚えておいてください。つまり(次のリリースで開発される予定です)。
このすべてできたテストで発見されることもありますが、異なるディストリビューションやリリースのバイナリを混ぜて組み合わせ始めると、パッケージとバイナリバージョンの正確な組み合わせをテストする最初の人になる可能性があります。それこれが推奨されない理由です。ほとんどのユーザーはシステムをテストするのではなく、使用したいからです。
もちろん、これはあなたの経験にも当てはまりますが、多くの場合、すべてがうまくいきます。これは、あなたが感じる偏見にも寄与しています。人々は、自分のZシステムにディストリビューションYからパッケージXをインストールした方法を説明する投稿（またはStack Exchangeのコンテキストでの質問）を書かない傾向があります。そのため、このドメインで目にするコンテンツのほとんどは、しなかったうまくいかなかったり、セットアップが複雑になったり、他のものを壊してしまったりする。そして、人々が、明示的に推奨されていることをすることで自ら招いた、おそらく一度きりの問題の解決に時間を費やすことを躊躇するのは当然である。に対して。