Benutzer-Werkzeuge

Webseiten-Werkzeuge


tipps:git

GIT

git update mit Tags

git fetch --tags
git pull

acroread_auf_Linuxmint 19

Quelle: Arnim

Abenteuer eines DAU beim Installieren proprietärer Software in Linux.

Des Lesens und Schreibens halbwegs mächtig, habe ich durchaus Verständnis für die Grundprinzipien des Urheberrechts. Folglich ist nachvollziehbar, daß nicht jeder, der sich mit dem Schreiben von Software quält, bereit ist, die Früchte seiner Bemühungen so ohne weiteres in allen Facetten mit tout le monde zu teilen. Diesbezüglich ein klassisches Beispiel ist die Firma Adobe, die vor langer Zeit den PDF-Standard entwickelte und im Sinne des fair-use jedem der wollte ein kostenfreies Programm zur Verfügung stellte, um Dokumente in diesem Standart lesen zu können: Der Acrobat-Reader. Juristisch war damit ein Vertrag zwischen Adobe und dem Nutzer die Bedingung, die letzterer zu akzeptieren hat. Das ist auch vollkommen in Ordnung. Der Standard setzte sich durch und ist für jeden inzwischen unumgänglich. Seit einigen Jahren allerdings gibt es eine weitere Bedingung: Der Nutzer muß nicht nur mit Adobe eine Vereinbarung akzeptieren, sondern auch Verträge mit Dritten eingehen, konkret er muß ein Betriebssystem der Firmen Microsoft oder Apple benutzen. Es gibt gewichtige Gründe dies nicht tun zu wollen. Auf der anderen Seite gibt es aber notwendige Dokumente für den "freien Bürger", die dieser nicht einfach ignorieren kann. Folglich hat sich Adobe selbst eine Verpflichtung geschaffen, die Zugänglichkeit zu PDF-Dokumenten sicher zu stellen. Dem ist Adobe nachgekommen, indem wesentliche Teile des PDF-Standards frei zugänglich sind, allerdings nicht mit allen Feinheiten. So kann es heute passieren, daß der unbescholtene Bürger für ihn notwendige PDF-Dokumente präsentiert bekommt, die für ihn nicht zugänglich sind, wenn er sich nicht in die Knechtschaft der Firmen Microsoft oder Apple begibt (ein "unverfängliches" Beispiel sind die Linienpläne des VRR). Hier kollidiert also die Freiheit des Urhebers Adobe mit der Vertragsfreiheit von "freien Bürgern". Umgangen werden kann dieses Problem also nur, indem entweder Adobe dazu verpflichtet wird, weiterhin eine betriebssystemunabhängige Lesesoftware zur Verfügung zu stellen oder indem es allen staatlichen und halbstaatlichen Organisationen untersagt wird, PDF-Dokumente zu erstellen, die nicht fehlerfrei von quelloffenen Acroreader-Alternativen dargestellt werden können. Soweit sind wir noch nicht...

In diesem Umfeld stellte sich also die Aufgabe, die letzte verfügbare Version des Acrobat-Reader in ein aktuelles Linuxsystem zu integrieren. Ja, es ist bekannt, daß sich dies nicht positiv auf die Sicherheit des Betriebssystems auswirkt. Aber was hilft ein "sicheres" System, wenn man damit benötigte Dokumente nicht öffnen kann? Gar nichts, dann könnte man besser auf dem Nordpol wandern gehen...

Konkret sollte das mit dem seit Juli 2018 verfügbaren Linuxmint19 geschehen. Der Acrobat-Reader 9.5.5-1 funktionierte auf der Vorgängerversion 18.3 noch reibungslos. Die Installation des von Adobe ausgelieferten Pakets "AdbeRdr9.5.5-1_i386linux_enu.deb" funktionierte auch in Linuxmint19 ohne Auffälligkeiten. Die Ausführung des Progamms bricht dann aber mit einer Fehlermeldung ab, weil die Datei "libxml.so.2" nicht auffindbar sei. Die Eingabe von "locate libxml.so.2" im Terminal zeigte aber auf, daß sie sich im Ordner /usr/lib/x86_64-linux-gnu/ befindet. Gut, da hat sich wohl etwas beim System geändert. Es lag nahe, daß der Reader die Datei im Ordner /usr/lib/i386-linux-gnu/ verortete. Quick and dirty, aber nahe liegend, wurde die entsprechende Datei dorthin kopiert. Da es sich inzwischen aber nicht mehr um eine Datei mit Inhalt, sondern lediglich um eine Verknüfung mit einer Datei namens "libxml2.so.2.9.4" handelt, wanderte eine Doublette letzterer auch in den 386er-Ordner, weil die Verknüpfungen nur eine relative und keine absolute Pfadangabe beinhalten. Erneuter Acroreadstart und tatsächlich kommt man auch einen Schritt weiter. Jetzt meckerte er über eine falsche "ELF class". Was auch immer das sein möge, da aber noch ein Linuxmint 18.3 vorhanden und die Methode des quick and dirty ohnehin schon in den Anwendung war, wurde von dort die Datei "libxml2.so.2.9.3" geholt. Die darauf verlinkende Datei "libxml.so.2" (also die Verküpfung aus LM 18.3) lies sich allerdings nicht auf einen USB-Stick kopieren. Nun verlinkt aber "libxml.so.2" aus LM 19 auf "...2.9.4" und nicht auf "...2.9.3". Folglich wurde die echte "...2.9.3" mittels Umbenennung zur unechten "...2.9.4". Das müßte eigentlich gehen, da ja sonst kein Progamm in LM 19 noch auf /usr/lib/i386-linux-gnu/libxml2.so.2.9.4 zugreifen sollte (die echte "...2.9.4" wird ja in /usr/lib/x86_64-linux-gnu gesucht, wo sie ja weiterhin vorhanden ist). Puristen und Ordnungsfanatiker werden gar nicht genug Hände haben, um sie über dem Kopf zusammen zu schlagen... Aber die dürften sowieso nicht bis hierher gelesen haben, denn die Grundaufgabe ist ja eigentlich schon indiskutabel. Im übrigen baut man sich so ein schönes Beispiel für "never change a running system", denn sollte ich im weiteren doch Erfolg haben, wird sich kaum noch ein vernünftiger Admin oder Programmierer mit meiner "Bastelbude" auseinandersetzen wollen.* Erneuter Start des Reader und - oh Wunder - auch hier kam er einen Schritt weiter. Nun allerdings fand er "libstdc++.so.6" nicht. Nun haben wir ja schon ein wenig Übung: Zu der Vernküfungsdatei "libstdc++.so.6" gehören die Dateien "libstdc++.so.6.0.25" (LM 19) und "libstdc++.so.6.0.21" (LM 18.3). Handling wie zuvor und im nächsten Schritt stellte Acrobat die Aufgabe "libicuuc.so.55". Damit es nicht langweilig wird findet man die Datei in LM 19 gar nicht. In LM 18.3 natürlich wieder im bewährten 386er-Ordner (aber auch in "x86_64"). Auch die aufgerufene Datei ist in Wirklichkeit eine Verknüpfung, womit sich das Problem mit dem USB-Stick stellte. Nehmen wir statt dessen eine externe Festplatte mit einem ext4-Dateisystem - funktionierte. Womit wir nebenbei noch lernten, daß Linuxverknüpfungen nicht auf FAT32-Datenträger kopiert werden können - warum auch immer. Ach ja, die dazugehörige Datei "mit Inhalt" nennt sich "libicuuc.so.55.1". Auch jetzt wurde mit einem Readerstart die nächste Aufgabe mit dem Namen "libicudata.so.55" gefunden. Damit und mit "libicudata.so.55.1" wurde wie zuvor verfahren und es dohte eine gewisse Langeweile. Weit gefehlt, ein "acroread" im Terminal brachte Farbe ins Spiel:

Gtk-Message: 17:59:26.521: Failed to load module "gail"
Gtk-Message: 17:59:26.544: Failed to load module "atk-bridge"

(acroread:9532): Gtk-WARNING **: 17:59:26.656: Im Modulpfad »mist« konnte keine Themen-Engine gefunden werden,

Aber letztlich kam das Fenster mit dem License Agreement! Auch diesmal habe ich - wie schon seit über 20 Jahren - akzeptiert und kann weiterhin die "kritischen" PDF-Dokumente nutzen. Dafür mussten vier in den Repositories nicht vorhandene Bibliotheken mit den dazu gehörigen Verknüpfungen in das System eingefügt werden.

Fazit: Das Beispiel taugt letztlich nicht für eine weitere Runde in der diskursiven Auseinandersetzung zwischen den Befürwortern und Gegnern proprietärer respektive quelloffener software, denn die Probleme für den DAU resultieren einfach aus mangelnder Rücksichtnahme der beiden Lager untereinander und gemeinsam auf den Kunden: Würde die Verzeichnisstruktur der Linuxsysteme nicht laufend geändert, könnte ein Programm noch lange nach der Einstellung der Weiterentwicklung nützliche Dienste leisten. Auf der anderen Seite erscheint es auch nicht als große Zumutung für professionelle Firmen, wenn sie ihre Softwarepakete vollständig packen würden, sodaß später vielleicht einmal obsolete Bibliotheken einfach mitgeliefert werden. Schaut man sich Installationsprogramme im Dosenbereich an, so ist das dort eher die Regel...

---
* Dieser Text ist paralell zur beschriebenen Aktion entstanden. Deswegen wußte ich an der Stelle noch nicht, ob das Ziel erreicht wird oder hier nur die Erkenntnis, wie man scheitern kann, gewonnen wird.

Versuch es knapper zu sagen:

Installation Adobe Pakets "AdbeRdr9.5.5-1_i386linux_enu.deb" in Linuxmint19 ohne Auffälligkeiten. Die Ausführung des Progamms bricht dann aber mit einer Fehlermeldung ab, weil die Datei "libxml.so.2" nicht auffindbar sei.
Lt. locate libxml.so.2 im Verz.  /usr/lib/x86_64-linux-gnu/ 
Dagegen sucht der Reader die Datei im Ordner /usr/lib/i386-linux-gnu/
Sowohl der Softlink libxml.so.2 als auch sein Ziel "libxml2.so.2.9.4" werden dorthin kopiert
falsche "ELF class"
aus älterer Linuxmint 18.3 versuchen wir "libxml2.so.2.9.3" zu holen
Die darauf verlinkende Datei "libxml.so.2" (also die Verküpfung aus LM 18.3) lies sich allerdings nicht auf einen USB-Stick kopieren. Nun verlinkt aber "libxml.so.2" aus LM 19 auf "...2.9.4" und nicht auf "...2.9.3". Folglich wurde die echte "...2.9.3" mittels Umbenennung zur unechten "...2.9.4". Das müßte eigentlich gehen, da ja sonst kein Progamm in LM 19 noch auf /usr/lib/i386-linux-gnu/libxml2.so.2.9.4 zugreifen sollte (die echte "...2.9.4" wird ja in /usr/lib/x86_64-linux-gnu gesucht, wo sie ja weiterhin vorhanden ist)
  * "libstdc++.so.6" nicht gefunden
  *  Zu der Vernküfungsdatei "libstdc++.so.6" gehören die Dateien "libstdc++.so.6.0.25" (LM 19) und "libstdc++.so.6.0.21" (LM 18.3). Handling wie zuvor und im nächsten Schritt stellte Acrobat die Aufgabe "libicuuc.so.55". Damit es nicht langweilig wird findet man die Datei in LM 19 gar nicht. In LM 18.3 natürlich wieder im bewährten 386er-Ordner (aber auch in "x86_64"). Auch die aufgerufene Datei ist in Wirklichkeit eine Verknüpfung, womit sich das Problem mit dem USB-Stick stellte. Nehmen wir statt dessen eine externe Festplatte mit einem ext4-Dateisystem - funktionierte. Womit wir nebenbei noch lernten, daß Linuxverknüpfungen nicht auf FAT32-Datenträger kopiert werden können - warum auch immer. Ach ja, die dazugehörige Datei "mit Inhalt" nennt sich "libicuuc.so.55.1". Auch jetzt wurde mit einem Readerstart die nächste Aufgabe mit dem Namen "libicudata.so.55" gefunden. Damit und mit "libicudata.so.55.1" wurde wie zuvor verfahren und es dohte eine gewisse Langeweile. Weit gefehlt, ein "acroread" im Terminal brachte Farbe ins Spiel:

Gtk-Message: 17:59:26.521: Failed to load module "gail"
Gtk-Message: 17:59:26.544: Failed to load module "atk-bridge"

(acroread:9532): Gtk-WARNING **: 17:59:26.656: Im Modulpfad »mist« konnte keine Themen-Engine gefunden werden,

Aber letztlich kam das Fenster mit dem License Agreement! Auch diesmal habe ich - wie schon seit über 20 Jahren - akzeptiert und kann weiterhin die "kritischen" PDF-Dokumente nutzen. Dafür mussten vier in den Repositories nicht vorhandene Bibliotheken mit den dazu gehörigen Verknüpfungen in das System eingefügt werden.
tipps/git.txt · Zuletzt geändert: 30.08.2018 14:45 von arno