Was führt zu Paket-/Binärinkompatibilität?

Question

Folgend aufIst die Ubuntu LTS-Binärdatei mit Debian kompatibel?

Ich weiß, dass Binärpakete von Ubuntu und Debian häufig inkompatibel sind. Ich weiß, dass es im Allgemeinen keine gute Idee ist, Pakete aus verschiedenen Quellen zu mischen, und die Leute werden ständig davor gewarnt. Beschränken wir die Diskussion also auf rein technische Aspekte –

Was genau führt zu Inkompatibilitäten bei Paketen aus unterschiedlichen Quellen, wenn die Abhängigkeiten natürlich nicht das Problem sind?

------ Trennung, weitere Einzelheiten weiter unten ------

Wiedas Sprichwort:

über die binäre Kompatibilität (https://wiki.ubuntu.com/MarkShuttleworth#What_about_binary_compatibility_between_distributions.3F): Debian-Pakete werden wahrscheinlich mit unterschiedlichen Toolchain-Versionen erstellt, daher können Probleme auftreten

Warum verursachen unterschiedliche Toolchain-Versionen Probleme?

• Ich weiß, wie ich den Mindestsatz an Paketen von Debian Sid in meinen Debian-Stall ziehen kann, und habe das die ganze Zeit getan.
• Ich habe Pakete von älteren Versionen von Ubuntu / Debian auf neuere Versionen übertragen, oder sogar
• Kopieren einer einzelnen ausführbaren Datei von meinem Ubuntu / Debian in eine andere Distribution, sei es RedHat oder sogar FreeBSD,

Undniemalshatte vorher ein Problem. Was also genau verursacht das Problem, von dem die Leute sprechen?

Ist es die GCC- oder Kernel-Version? Das ist für mich unwahrscheinlich, da sie während der gesamten Nutzungsdauer dieser Version ständig aktualisiert werden.

Es handelt sich also um die Version von glibc? Aber normalerweise und höchstwahrscheinlich ist sie abwärtskompatibel, oder?

Zitat aus der Antwort auf meinen ersten Link:

Es gibt wirklich keine Garantie oder Implikation für Cross-Kompatibilität. Erwarten Sie nicht, dass die Debian- oder Ubuntu-Communitys Ihnen viel Mitgefühl entgegenbringen, wenn etwas schief geht. In diesem Fall sind Sie größtenteils auf sich allein gestellt. Solange Sie damit einverstanden sind, können Sie es ruhig ausprobieren.

Im Grunde sehe ich überall Warnungen vor dieser Vorgehensweise, aber niemand gibt weitere technische Erklärungen. Kann jemand bitte die damit verbundenen Risiken und die potenziellen technischen Probleme auflisten?

Wenn ich Pakete aus unterschiedlichen Quellen, beispielsweise Debian oder Ubuntu, oder aus derselben Distribution, aber unterschiedlichen Versionen mischen möchte/muss (wenn die Abhängigkeiten nicht das Problem sind), hilft mir diese Antwort dabei, die sicherste Vorgehensweise zu wählen und ein PPA, von dem ich sicher weiß, dass es nie in Debian landen wird, in das Debian Bullseye zu ziehen, das ich derzeit verwende.

Answer 1

Binär- und Paketinkompatibilitäten sind unterschiedlich und sollten gesondert erklärt werden.

Binäre Inkompatibilität

Dies ist normalerweise gemeint, wenn über Unterschiede in der Toolchain usw. gesprochen wird.WerkzeugketteInkompatibilitäten selbst sind ungewöhnlich, da die Toolchain neben dem Kernel einer der Bereiche ist, in denen Entwickler am sorgfältigsten auf die Wahrung der Abwärtskompatibilität achten. Daher sollte eine in der Vergangenheit erstellte Binärdatei weiterhin ausgeführt werden, solange siebinärAbhängigkeiten bleiben weiterhin verfügbar. Das läuft darauf hinaus, die benötigten Bibliotheken beizubehalten.

Was schief läuft, ist die Vorwärtskompatibilität: Es kann nicht garantiert werden, dass eine „in der Zukunft“ erstellte Binärdatei ausgeführt wird. Dies zeigt sich häufig in fehlenden Symbolen in der C-Bibliothek (die erkannt werden, weil die Entwickler der C-Bibliothek sehr darauf achten, die Kompatibilität aufrechtzuerhalten). Man könnte meinen, dass sich die C-Bibliothek nicht viel ändert, sodass beim Erstellen eines Programms mit verschiedenen C-Bibliotheken die benötigten Symbole nicht geändert werden sollten und es kompatibel bleiben sollte. Das ist nicht der Fall, und Funktionen ändern sich regelmäßig auf abwärtsinkompatible Weise; die C-Bibliothek behältrückwärtsKompatibilität, indem weiterhin Versionen von Funktionen bereitgestellt werden, die mit früheren Schnittstellen kompatibel sind, mit einem entsprechenden Versionssymbol. Beispielsweise weist Version 2.33 der GNU C-Bibliothek inkompatible Änderungen an so häufigen Funktionen wie der statFamilie ( fstat/ lstat/ statusw.) auf. Ein mit einem Standard-Setup von 2.33 erstelltes Programm, das diese Funktionen verwendet, erfordert Version 2.33 der C-Bibliothek, um ausgeführt zu werden.

Toolchain-bezogene Bibliotheken und die C-Bibliothek werden so gepflegt, dass solche Inkompatibilitäten als Änderungen an Bibliothekssymbolen oder Soname-Änderungen angezeigt werden und somit in Paketabhängigkeiten codiert enden (für gepackte Software) oder vom dynamischen Linker abgefangen werden (für separate Binärdateien).

In Bibliotheken, die nicht so sorgfältig gepflegt werden wie die C-Bibliothek, treten solche Inkompatibilitäten nicht so sofort auf, sondern erst, wenn die fehlerhafte Kombination getestet wird (und selbst dann vielleicht nur unter bestimmten Umständen). Distributionsentwickler testen Pakete normalerweise nur im Kontext der gerade entwickelten Version. Sie wissen also nicht, dass das Paket, das sie für Ubuntu 20.04 erstellt haben, zwar korrekt auf Debian 10 installiert wird, aber Ihr Eichhörnchen tötet, wenn Sie es zwischen 1 und 2 Uhr MESZ am 21. Juni verwenden.

Das führt uns direkt zu ...

Paket-Inkompatibilität

Ob dies bewusst geschieht oder nicht, Pakete werden selten im Vakuum erstellt, sondern sind Teil einer Distributionsversion. Dies beginnt mit der Paketquelle (und allgemeiner mit der Projektquelle) selbst: Projekte und Pakete werden auf den Systemen ihrer Entwickler erstellt und kodieren ihre Abhängigkeiten möglicherweise nicht genau, es sei denn, es wird großer Aufwand betrieben.

Dies wirkt sich auf Binärpaketabhängigkeiten und in der Dokumentation beschriebene Abhängigkeiten aus. Einem Projektbetreuer ist möglicherweise nicht bewusst, dass sein Projekt in seiner aktuellen Konfiguration nur funktioniert, weil beispielsweise systemd Version 239 damit begonnen hat, das System auf eine bestimmte Weise einzurichten. Paketbetreuer erkennen dies möglicherweise auch nicht, wenn die Version der Distribution, an der sie arbeiten, zufällig bereits Version 239 von systemd enthält (denken Sie daran, dass Distributionsbetreuer normalerweise in der Zukunft leben,dhsie entwickeln sich in der nächsten Version).

All daskönntedurch Tests entdeckt werden, aber sobald Sie anfangen, Binärdateien aus verschiedenen Distributionen und Releases zu mischen und anzupassen, sind Sie wahrscheinlich die erste Person überhaupt, die Ihre genaue Kombination aus Paket- und Binärversionen testet. UndDasist der Grund, warum dies nicht empfohlen wird: Die meisten Benutzer möchten ihre Systeme verwenden und nicht testen.

Natürlich, und das passt zu Ihrer Erfahrung, funktioniert in vielen Fällen einfach alles. Dies trägt auch zu der von Ihnen wahrgenommenen Voreingenommenheit bei: Die Leute neigen dazu, keine Beiträge (oder Fragen im Stack Exchange-Kontext) zu schreiben, in denen sie erklären, wie sie Paket X von Distribution Y auf ihrem Z-System installiert haben und es einfach funktioniert hat. Der Großteil des Inhalts, den Sie in dieser Domäne sehen, sind also Szenarien, in denen Dingenichtfunktionierte, oder die Einrichtung war kompliziert, oder etwas anderes ging kaputt; und die Leute sind verständlicherweise nicht bereit, Zeit damit zu verbringen, jemandem bei der Behebung eines wahrscheinlich einmaligen Problems zu helfen, das sie selbst verursacht haben, indem sie etwas getan haben, was ausdrücklich empfohlen wurdegegen.