Distro-Name, glibc oder Compiler: Was der Installer prüft

Der Installer gibt “unsupported distribution” aus, Sie ändern eine Zeichenkette, und er läuft weiter, bis er eine Minute später mit einem Loader-Fehler abbricht. Diese Abfolge ist das Symptom, das man erkennen sollte: Der erste Fehler war eine Erkennungsprüfung, der zweite ist eine Kompatibilitätsgrenze. Es sind zwei verschiedene Probleme, die zufällig im selben Terminal auftauchen. Die Prüfung zu ändern kann Sie nur vom ersten zum zweiten bringen.

Das Symptom: Der Installer bleibt bei Ihrer Derivatsdistribution stehen

Ein Skript, das einen Distributionsnamen liest und die Fortsetzung verweigert, sagt Ihnen, dass sein Autor Ihr Derivat nicht getestet hat. Das ist eine Support-Aussage und keine technische Tatsache, und sie ist oft insofern falsch, als das Paket einwandfrei laufen würde.

Der Ärger beginnt, wenn der Workaround zum Plan wird. Das Ändern einer Identitätsdatei lässt die Prüfung durchgehen, und das Paket lädt dann gegen die tatsächlich installierte Laufzeit – oder lädt nicht. Scheitert es dort, hilft keine weitere Identitätsänderung.

Der nützliche Schritt ist daher herauszufinden, welche Frage der Installer gestellt hat, und dann herauszufinden, ob die Antwort eine Rolle gespielt hätte. Das sind zwei getrennte Untersuchungen, und nur die zweite sagt voraus, ob das Paket funktionieren wird.

Drei Versionen, die man die Systemversion nennt

Eine Distributionsversion benennt eine paketierte Umgebung. Eine C-Bibliotheksversion benennt eine Laufzeitimplementierung und ihre Version. Eine Compilerversion benennt eine Toolchain. Im Gespräch nennen Leute alle drei “die Systemversion”, und in einem Installer sind sie nicht austauschbar.

cat /etc/os-release
ldd --version | head -1
gcc --version | head -1
uname -m

Eine vorgebaute Anwendung erwartet die Laufzeit, die beim Linken vorhanden war. Compiler auf dem Host auszutauschen linkt sie nicht neu, und eine neuere Toolchain ändert nichts an den Loader-Symbolen, die das Binary anfordert. Die Architektur zählt wieder separat, denn ein 32-Bit-Paket auf einem 64-Bit-System scheitert aus Gründen, die keine Versionszeichenkette erklärt.

Bewahren Sie die vier Ausgaben beim Bericht auf. Sie zu sammeln dauert zehn Sekunden, und sie beantworten die meisten Fragen, die ein Maintainer Ihnen sonst per E-Mail stellen würde.

Lesen Sie den Fehler, nicht die Prüfung

Der erste Startfehler ist der Beweis. Eine Meldung über ein fehlendes gemeinsames Objekt oder über eine Symbolversion, die der Loader nicht erfüllen kann, ist ein Laufzeitabhängigkeitsproblem. Eine Meldung, die den Distributionsnamen wiederholt, ist wieder die Erkennungsprüfung, an anderer Stelle.

Die Dokumentation des dynamischen Linkers beschreibt, wie die Bibliothekssuche funktioniert und wo der Loader sucht. Ein Distributionslabel zu ändern fügt diesem Suchpfad kein Verzeichnis hinzu, weshalb der zweite Fehler unabhängig vom ersten wirkt.

Greifen Sie nicht als beiläufigen ersten Schritt zu ldd auf einer heruntergeladenen ausführbaren Datei. Das eigene Handbuch warnt, dass es das Programm unter Umständen ausführen kann, und einen nicht vertrauenswürdigen Installer auszuführen ist genau der Fall, um den es in dieser Warnung geht.

Warum das Bearbeiten der Zeichenkette nicht hilft

Die Identität des Betriebssystems zu fälschen ändert, wie jedes Programm auf der Maschine sich selbst sieht. Paketmanager, Supportwerkzeuge und andere Anwendungen lesen dieselbe Datei, und ein Wert, der einen Installer zufriedenstellt, kann Monate später etwas anderes verwirren.

Host-Bibliotheken durch Dateien aus einer anderen Distribution zu ersetzen ist schlimmer. Es kann unbeteiligte Software brechen, es ist für den Paketmanager unsichtbar, und es braucht einen Wartungsplan, den niemand aufschreibt. Diese Änderungen rechtfertigt ein einzelner restriktiver Installer nicht.

Ist die Prüfung tatsächlich ein Erkennungsfehler, kann der Maintainer ihn bestätigen und die unterstützte Korrektur beschreiben. Ist sie kein Fehler, ist der unterstützte Weg ein Build für Ihre Plattform, und diese Antwort ändert sich nicht dadurch, dass die Zeichenkette bearbeitet wurde.

Schreiben Sie einen Bericht, mit dem der Maintainer arbeiten kann

Halten Sie Distribution und Version, die Architektur, die VPN-Version, die genaue abgelehnte Bedingung und den ersten Laufzeitfehler fest, falls Sie so weit gekommen sind. Vermerken Sie, ob Sie etwas geändert haben, denn ein Bericht von einem geänderten System ist ein anderer Bericht.

Lassen Sie den ursprünglichen Installer unverändert und beschreiben Sie die Prüfung, statt sie zu umgehen. Diese Unterscheidung erlaubt es dem Maintainer, eine zu enge Erkennungsregel von einer echten binären Kompatibilitätsgrenze zu trennen, und das sind zwei sehr verschiedene Fehler mit zwei sehr verschiedenen Korrekturen.

Kommt die Antwort zurück, dass Ihre Plattform nicht unterstützt wird, ist das ein brauchbares Ergebnis. Es sagt Ihnen, nach einem unterstützten Build zu suchen, statt einen weiteren Abend mit Identitätsdateien zu verbringen, die nie das Problem waren.