フォローアップ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の他のディストリビューションにコピーします。
そしていいえ以前にも問題がありました。それでは、人々が話す問題の原因は正確に何ですか？
gccですか、それともカーネルバージョンですか？そのバージョンの使用中に生涯にわたってアップグレードされたので、私にとっては少ない可能性があります。
それではglibcのバージョンですか？しかし、通常、以前のバージョンと互換性があり、これはかなり可能です。そうですか？
私の最初のリンクの答えを引用すると、次のようになります。
相互互換性は実際には保証も暗示もされません。問題が発生した場合は、DebianやUbuntuコミュニティから多くの同情を期待しないでください。この場合、基本的にはあなた自身です。あなたがそれについて快適さを感じる限り、自由に試してみてください。
だから基本的に私はこの慣行に関する警告をどこでも見ることができますが、誰もそれ以上の技術的な説明を提供しません。誰もがこのタスクのリスク、潜在的な技術的な問題をリストできますか？
他のソース（DebianやUbuntuなど）のパッケージを混在させるか、同じディストリビューションですが、異なるバージョンのパッケージを混在させたい場合（または依存関係が問題ではない場合）、この答えは最も安全なアプローチを選択するのに役立ちますです。 PPA私はDebian、つまり私が現在使っているDebian Bullseyeには決して現れないと確信しています。
答え1
バイナリとパッケージの非互換性は異なるため、別々に説明する必要があります。
バイナリ非互換性
これは一般に、人々がツールチェーンの違いなどについて話すときに言及されます。ツールチェーンカーネルと同様に、ツールチェーンは開発者が以前のバージョンとの互換性を維持するために最も注意を払うべき領域の1つであるため、非互換性自体が珍しいものです。したがって、過去にビルドされたバイナリは、そのバイナリが実行されている限り実行する必要があります。バイナリ依存関係は引き続き使用可能であり、これは必要なライブラリを維持することに依存します。
問題は親互換性にあります。 「将来」ビルドバイナリは実行を保証しません。これは通常、Cライブラリに欠けている記号で示されています（これは、Cライブラリ開発者が互換性を維持するために慎重に注意を払ったために検出されたものです）。 Cライブラリはあまり変わらないと思うかもしれませんので、他のCライブラリを使ってプログラムをビルドしても、必要なシンボルを変更してはならず、互換性を維持する必要があります。そうではありません。関数は、Cライブラリが保持する以前のバージョンと互換性のない方法で定期的に変更されます。戻る互換性は、適切なバージョン記号と共に、以前のインターフェースと互換性のある機能バージョンを提供し続けることによって達成される。たとえば、GNU Cライブラリバージョン2.33では、ファミリstat（fstat//lstatなど）statなど、一般的に使用される機能を互換性がないように変更しました。これらの機能の2.33デフォルト設定でビルドされたプログラムを実行するには、Cライブラリバージョン2.33が必要です。
ツールチェーン関連ライブラリとCライブラリは、これらの非互換性がライブラリシンボルの変更または名前変更として表示され、最終的にパッケージの依存関係（パッケージソフトウェアの場合）にエンコードされるか、動的リンカ（個々のバイナリファイルの場合）にキャプチャされるように維持されます。 ）。
Cライブラリと同じくらい注意深く管理されていないライブラリでは、これらの非互換性はすぐには表示されず、間違った組み合わせをテストしたときにのみ表示されます（そしてその場合でもいくつかの場合にのみ表示されます）。 Distro開発者は通常、開発中のディストリビューションのコンテキストでのみパッケージをテストするため、Ubuntu 20.04用に構築されたパッケージがDebian 10に正しくインストールされているかどうかはわかりませんが、6月午前1時（CEST）にインストールするとわかりません。 2から21の間に使用すると、ペットリスが死ぬでしょう。
これは良い結果につながります...
パッケージ非互換性
意識的であるかどうかにかかわらず、パッケージは真空で構築されることはほとんどなく、ディストリビューションの一部です。これはパッケージソース（より一般的にはプロジェクトソース）自体から始まります。プロジェクトとパッケージは開発者のシステムに構築されており、大きな努力がなければ、その依存関係が正確にコード化されない可能性があります。
これは、ドキュメントで説明されている依存関係だけでなく、バイナリパッケージの依存関係にも影響します。プロジェクトメンテナは、自分のプロジェクトが現在の構成でのみ機能していることに気づいていない可能性があります。たとえば、systemdバージョン239がシステムを特定の方法で設定し始めたためです。パッケージマネージャは、自分が作業しているディストリビューションにすでにシステム化されている239バージョンがある場合、それを認識しない可能性があります（ディストリビューションマネージャは通常将来に住んでいます。つまり次のバージョンで開発される予定です。）
これらすべてできるテストにかかりましたが、いったんさまざまなディストリビューションとバージョンのバイナリを混在させ、一致させ始めたら、パッケージとバイナリバージョンの正確な組み合わせを最初にテストできます。そしてそれこれが推奨されない理由です。ほとんどのユーザーは、システムをテストするのではなく使用したいと考えています。
もちろん、これはあなたの経験と一致し、ほとんどの場合、すべてがうまく機能します。これは偏見の認識にも寄与します。人々は、システムZのDistro YからパッケージXをインストールする方法を説明する投稿（またはStack Exchange環境の質問）を作成しない傾向がありますが、うまくいきます。だからこの空間で見るほとんどはシーンです。いいえタスクを実行したり、設定が複雑になったり、他のものを破ったりする可能性があります。人々が明示的に推奨するタスクを実行して発生したワンタイム問題を解決するのに時間をかけたくないことは理解できます。反対する。