什麼引入了包/二進制不兼容？
跟進Ubuntu LTS 二進製文件是否與 Debian 兼容？
我知道 Ubuntu 和 Debian 二進制包經常不兼容。我知道混合來自不同來源的軟體包通常是一個壞主意，人們總是被警告不要這樣做。所以讓我們保持純技術性的討論——
當依賴關係當然不是問題時，究竟什麼會導致來自不同來源的包不兼容？
—— 分離，下面有更多細節 ——
就像那句話：
關於二進制兼容性（https://wiki.ubuntu.com/MarkShuttleworth#What_about_binary_compatibility_between_distributions.3F）：Debian 軟體包可能使用不同的工具鏈版本建構，因此您可能會遇到麻煩
為什麼不同的工具鏈版本會出現問題？喜歡
- 我知道如何將 Debian sid 中的最小軟體包集提取到我的 Debian 穩定版中，並且一直在這樣做，
- 我曾經將軟體包從舊版本的 Ubuntu / Debian 帶到他們的新版本，甚至
- 將單個執行檔從我的 Ubuntu / Debian 複製到另一個發行版，無論是 RedHat 還是 FreeBSD，
並且以前從未遇到過問題。那麼究竟是什麼導致了人們所說的問題呢？
是 gcc 還是核心版本？對我來說不太可能，因為它們在我使用該版本的整個生命週期中一直在升級。
所以它是glibc的版本？但它通常會向後兼容，而且很有可能，對吧？
引用我的第一個連結的答案：
確實不能保證甚至暗示交叉兼容性。如果出現問題，不要指望 Debian 或 Ubuntu 社區會給予你太多的同情。在那種情況下，你主要是靠自己。只要您對此感到滿意，請隨時嘗試一下。
所以基本上我到處都看到對這種做法的警告，但沒有人給出進一步的技術解釋。誰能列出這樣做的風險，那些潛在的技術問題？
如果我想/需要混合來自不同來源的軟體包，比如 Debian 或 Ubuntu，或者在同一個發行版但不同的版本中，（如果依賴關係不是問題），這個答案將幫助我選擇最安全的方法，拉我確定的 PPA 永遠不會出現在 Debian 中，進入我目前使用的 Debian Bullseye。
二進制和包不兼容是不同的，值得單獨解釋。
二進制不兼容
這通常是人們談論工具鏈差異等時所提到的。工具鏈不兼容本身是不尋常的，因為工具鏈與核心一樣，是開發人員在保持向後兼容性方面最小心的領域之一。因此，過去建構的二進製文件應該繼續執行，只要它的二進制依賴項繼續可用；這歸結為保留它需要的庫。
問題在於前向兼容性：不能保證“未來”建構的二進製文件能夠執行。這通常顯示為 C 庫中缺少的符號（由於 C 庫開發人員非常注意維護兼容性，因此可以準確檢測到這些符號）。有人可能認為 C 庫沒有太大變化，因此用不同的 C 庫建構程序不應該改變它需要的符號，並且應該保持兼容。情況並非如此，功能確實會以向後不兼容的方式定期更改；C 庫通過繼續提供與先前介面兼容的函式版本以及適當的版本符號來保持*向後兼容性。*例如，GNU C 庫的 2.33 版對諸如
stat家庭（fstat/lstat/stat等）；使用這些函式以預設設置 2.33 建構的程序將需要 2.33 版的 C 庫才能執行。與工具鏈相關的庫和 C 庫的維護方式使得此類不兼容性顯示為庫符號更改或 soname 更改，因此最終編碼在包依賴項中（對於打包的軟體）或被動態連結器擷取（對於單獨的二進製文件）。
在沒有像 C 庫那樣精心維護的庫中，這種不兼容性不會立即出現，它們只會在測試錯誤組合時才會出現（即使那樣，也可能僅在某些情況下）。發行版開發人員通常只在正在開發的版本的上下文中測試軟體包，所以他們不會知道他們為 Ubuntu 20.04 建構的軟體包是否可以在 Debian 10 上正確安裝，但如果你在 6 月 CEST 凌晨 1 點到 2 點之間使用它會殺死你的寵物松鼠21.
這很好地導致…
包不兼容
無論是否有意識地這樣做，軟體包很少是在真空中建構的，它們是分發版本的一部分。這從包源（更一般地，項目源）本身開始：項目和包是在其開發人員的系統上建構的，除非付出很大的努力，否則可能無法準確地編碼它們的依賴關係。
這會滲透到二進制包依賴項以及文件中描述的依賴項。項目維護者可能沒有意識到他們的項目在其目前配置下只能工作，因為例如 systemd 版本 239 開始以某種方式設置系統。軟體包維護者也可能沒有意識到，如果他們正在開發的發行版恰好已經有 systemd 的 239 版本（請記住，發行版維護者通常生活在未來，即他們在下一個版本中開發）。
所有這些都可以通過測試來捕捉，但是一旦你開始混合和匹配來自不同發行版和發行版的二進製文件，你很可能是第一個測試你的包和二進製版本的確切組合的人。這就是不建議這樣做的原因：大多數使用者想要使用他們的系統，而不是測試它們。
當然，這符合您的經驗，在許多情況下一切正常。這也助長了您所感知的偏見：人們傾向於不寫文章（或問題，在 Stack Exchange 上下文中）解釋他們如何在 Z 系統上安裝來自發行版 Y 的包 X，並且它只是工作。所以你在這個領域看到的大部分內容都是一些事情沒有工作的場景，或者最終設置起來很複雜，或者破壞了其他東西；可以理解的是，人們不願意花時間幫助某人解決一個可能是一次性的問題，這些問題是他們通過做一些明確建議反對的事情給自己帶來的。