Zunächst einmal habe ich diese ähnliche Frage gefundenWie erstelle ich eine portable Linux-App?aber es geht nicht wirklich auf meine Fragen ein, es geht eher darum, wie man kompiliert, um die Anwendung portierbar zu machen, was ich bereits kann (zumindest glaube ich das), und nicht um die Bereitstellung, wie ich weiter unten erklären werde.
Das ist meine Situation. Wir wurden beauftragt, ein bestimmtes Problem für einen Kunden zu lösen, also werden wir eine Closed-Source-Anwendung entwickeln, die wir an ihn verkaufen möchten. Wir haben jedoch keine genauen Angaben darüber erhalten, wo sie laufen soll, also welche Distribution, Kernel-Version oder sonst was. Die Aufgabe ist ziemlich einfach und hängt nicht von Low-Level-Treibern oder irgendetwas ab, das die Portabilität erschweren würde. Wir sind jedoch auf einige Bibliotheken von Drittanbietern angewiesen. Im Folgenden sehen Sie ein einfaches Schema der Abhängigkeiten:
app --+-- libA
| +-- lib1
+-- libB --+-- lib2
+-- lib3
Wobei libA,B und lib1,2,3 allesamt Open-Source-Projekte mit geeigneten Lizenzen (LGPL, ASL und BSDs) sind. Nach der Kompilierung werden die gemeinsamen Abhängigkeiten unseres Programms zu libA, libB, lib1, lib2, lib3 und einer Reihe von Systembibliotheken wie libc, libm, libz, libstdc++, libpthread usw. Alles ist dynamisch verknüpft.
Da wir keine Zieldistribution haben, möchten wir dies unabhängig von Verpackungssystemen wie .deb oder dergleichen halten. Die direkten Abhängigkeiten (libA und libB) sind nicht sehr verbreitet, daher ist es naheliegend, sie zusammen mit unserer Anwendung bereitzustellen. lib1,2,3 sind tatsächlich weiter verbreitet (z. B. ist eine davon libpng), obwohl noch nicht sicher ist, ob sie im Zielsystem installiert werden. Wir haben uns entschieden, alle 5 davon in das endgültige Softwarepaket aufzunehmen.
Womit wir nichts anfangen können, sind die Systembibliotheken. Wie sollen wir damit umgehen? Gehen wir einfach davon aus, dass sie die richtigen Bibliotheken haben und hoffen auf das Beste? Was würde in einem solchen Fall in ein oder zwei Jahren passieren, wenn sich eine dieser Bibliotheken ändert und unsere Anwendung nicht mehr funktioniert?
Sollten wir sie alle (libstdc++, glibc usw.) mit unserer Software verteilen? Das fühlt sich nicht richtig an und ich denke, es verstößt möglicherweise gegen die darin enthaltenen Lizenzbedingungen. Ich weiß, dass ich in der Vergangenheit einige Programme verwendet habe, die tatsächlich ihre eigene Kopie von [zumindest] einigen dieser Bibliotheken enthielten. Das hat meine Aufmerksamkeit erregt, weil es eine ältere Version als die auf meinem System war und das Austauschen dazu führte, dass alles nicht mehr funktionierte (was ich zufällig herausfand).
Wie wird dies normalerweise gehandhabt?
Antwort1
Der strikt korrekte Ansatz für portable Binärdateien unter Linux besteht darin, gegen dieLinux Standard Baseund seindetaillierte Spezifikationen. Das LSB wurde entwickelt, um binäre Kompatibilität zwischen kompatiblen Distributionen herzustellen, indem es bestimmte Bibliotheksversionen (oder Kompatibilität mit diesen Versionen) angibt. Das LSB (oder zumindest eine frühere Version) wurde formalisiert alsISO/IEC 23360. Wenn Sie Ihr Programm so erstellen, dass es nur mit LSB-Bibliotheken (und den mitgelieferten) verknüpft wird, ist es zwischen all diesen Systemen portierbar.
Das LSB gibt das RPM-Format für Pakete an, Sie müssen also (streng genommen) nur eines erstellen. Ein Tarball reicht auch aus, wenn Sie auf die Integration mit dem Paketmanager verzichten.
In Bezug auf einige Ihrer spezifischen Punkte:
Können wir einfach davon ausgehen, dass sie über die richtigen Bibliotheken verfügen und das Beste hoffen?
Ein relativ einfaches LSB-kompatibles Programm wird wahrscheinlich auf vielen Systemen so, wie es ist, laufen, also könnten Sie das tun.
Darüber hinaus versuchen mehrere Distributionen, LSB-Kompatibilität bereitzustellen, darunter RHEL und SUSE. Einige andere bieten dies über ein spezielles Paket an, das die entsprechenden Abhängigkeiten einbezieht. Beispielsweise hat DebianEin Packetlsbdas zieht ein lsb-coreund mehrere andere, die wiederum die entsprechenden Abhängigkeiten einziehen. Es ist möglich, dass die Zielsysteme ein solches Paket installieren müssen, um Ihre Software auszuführen.
Das LSB ist weniger beliebt als früher und die formale Kompatibilität hat bei vielen Systemen nachgelassen, aber in der Praxis ist es möglich, es über einen ziemlich großen Bereich portabel auszuführen. Sogar einige Systeme, die nach Kompatibilität streben, übersehen einige der weniger bekannten Punkte, aber für allgemeine Zwecke spielt dies oft keine Rolle (und dieselben Programme funktionieren möglicherweise auf Systemen, dienichtVersuch, LSB-kompatibel zu sein).
Was würde in einem solchen Fall in ein oder zwei Jahren passieren, wenn sich eine dieser Bibliotheken ändert und unsere Anwendung nicht mehr funktioniert?
Wenn Ihre Anwendung nicht mehr funktioniert, wird Ihre Anwendung nicht mehr funktionieren. Dies ist eine Frage des Geschäftsprozesses.
Sollten wir sie alle (libstdc++, glibc usw.) mit unserer Software verteilen?
Wahrscheinlich nicht. Insbesondere bei libc kann es Laufzeitkompatibilitätsprobleme geben, wenn mehrere Versionen gleichzeitig auf einem System verwendet werden. Es gibt jedoch andere libc-Implementierungen, die sich möglicherweise praktischer bündeln lassen.
Während die meisten Bibliotheken erfolgreich gebündelt werden können, ist das Verteilen von Bibliotheken an Händler im Allgemeinen ein Wartungs- und Sicherheitsproblem. Ich rate daher davon ab, wenn es vermieden werden kann. Wenn in einer Bibliothek ein Fehler oder eine Sicherheitslücke entdeckt wird, ist es einfacher und zuverlässiger, sie an einer Stelle im System zu aktualisieren, wo die Distribution sie behebt, als jede Kopie aufzuspüren (und Ersatzpakete von Ihnen zu erhalten!).
Ein praktischerer Schritt wäre, Ihren Kunden zu fragen, wo er es laufen lassen möchte. Vielleicht sind Sie zu enthusiastisch.
Antwort2
In der Praxis müssen SiemehrereBinärpakete (z. B. .debfür Debian und Ubuntu, .rpmfür Fedora) für die gängigsten Linux-Distributionen (und Versionen). Natürlich müssen Sie für Fedora und Ubuntu unterschiedliche Pakete erstellen, und möglicherweise müssen Sie für Debian Jessie und Ubuntu 16.04 ein anderes Paket erstellen.ManchmalEin Paket für Ubuntu kann auf einem (bestimmten) Debian installiert werden und umgekehrt.
Wir haben jedoch keine genauen Angaben darüber erhalten, wo es ausgeführt werden kann. Damit meine ich, welche Distribution, Kernel-Version oder sonst etwas.
Sie müssen es mit Ihrem Kunden besprechen.
Was würde in einem solchen Fall in ein oder zwei Jahren passieren, wenn sich eine dieser Bibliotheken ändert und unsere Anwendung nicht mehr funktioniert?
Sie müssen neuere Varianten Ihrer Binärpakete erstellen und veröffentlichen und dafür Aufwand (und Geld) aufwenden.
Möglicherweise möchten Sie einige Bibliotheken statisch verknüpfen (sofern technisch und rechtlich möglich). (Denken Sie daran, dass die LGPL-Lizenz eine dynamische Verknüpfung empfiehlt oder die Möglichkeit bietet, auf dem Client-Rechner erneut statisch zu verknüpfen.) Beispielsweise libstdc++ist viel versionenempfindlicher als , libcdaher können Sie statisch libstdc++und dynamisch verknüpfen libc. In Wirklichkeit kann Ihre Anzahl variieren.
Beachten Sie, dassmehrereVersionen einer bestimmten Systembibliothek können in der Praxis funktionieren oder auch nicht. Einige Bibliotheken verwenden Systemressourcen auf eine bestimmte Weise, daher sind Details sehr wichtig.
PS. Vielleicht sollten Sie mit Ihrem Kunden mehr darüber diskutieren und anbieten, eine kostenlose Software (Open Source) zu entwickeln. Manche Kunden bevorzugen das vielleicht.