Ich habe eine PM bezüglich Erklärung von RPMs erhalten, und da ich denke, dass das von allgemeinem Interesse ist, hier ein paar Infos zu dem Thema der Software-Installation unter Linux.
Die meiste Software unter Linux ist quelloffen, das heißt, sie wird von den Programmierern im Quellcode verteilt, den man lesen und ändern kann, wenn man die jeweilige Programmiersprache beherrscht. Da der Quellcode als solcher bei den meisten höheren Programmiersprachen (C, C++ usw.) zwar menschenlesbar ist, aber nicht vom Computer verwendet werden kann, muss solcher Quellcode vor der Benutzung kompiliert werden. Das war lange Zeit die einzige Methode unter Linux, um an neue Software zu kommen.
Die Softwareentwicklung unter Linux läuft zudem kooperativ und modular ab. Das heißt, Programmierer, zu deren Grundtugenden bekanntlich die Faulheit gehört, vermeiden es, das Rad immer wieder neu zu erfinden. Wenn daher Bibliotheken anderer Programme bestimmte Funktionen enthalten, dann greifen diese Programmierer gerne auf diese Bibliotheken zurück. Das ist etwa vergleichbar mit solchen Programmen wie k3b, die zwar als CD-Brennprogramm gelten, aber eigentlich nur eine grafische Oberfläche für ein Kommandozeilen-Programm eines ganz anderen Autors darstellen. Ist das Kommandozeilenprogramm nicht da, ist k3b bunt, aber nutzlos.
Diese Zusammenhänge zwischen Biblioteken und Programmen aus unterschiedlichen Quellen nennt man Abhängigkeiten (englisch Dependencies). Wer alle Software von Hand kompiliert, muss sich auch selbst um Abhängigkeiten kümmern, die ihrerseits neue Abhängigkeiten haben können usw. Das führt ziemlich schnell zu dem Problem der Dependency Hell, wie es auf Englisch so treffend bezeichnet wird.
Verschiedene Distributionen haben einen Weg gesucht, dieses Problem in den Griff zu kriegen, und daraus sind die verschiedenen Paketmanagementsysteme entstanden. Für alle Paketmanagementsysteme gilt, dass sie Abhängigkeiten berücksichtigen, d.h., wenn ein Paket installiert wird, werden alle weiteren notwendigen Pakete und wiederum deren Abhängigkeiten usw. ebenfalls installiert. Das führt bei korrekter Vorbereitung des Pakets zu einer reibungslosen Installation.
RPM ist der
Red Hat
Paket
Manager. Außer Red Hat benutzen mittlerweile auch andere Distributionen dieses Format, z.B. SuSE. Ein RPM enthält alle Programmteile in einem Paket. Die Programme sind dabei (wenn es sich nicht um Source-RPMs handelt, die im Namen ein src tragen sollten) bereits kompiliert. Aus diesem Grund ist es meist nicht ratsam, ein RPM für eine andere Distribution als die vorgesehene zu verwenden. Es kann nämlich sein, dass ein Paket für Distri A z.B. eine bestimmte Bibliothek in /usr/local/lib erwartet, die in einer anderen Distri in /usr/lib liegt. Das RPM kann zwar installiert werden, aber das Programm funktioniert nicht.
Die Paketmanagement-Software der Distributionen greift normalerweise auf spezifische Repositorien zurück, die zu der jeweiligen Distri gehören, z.B. Yast für SuSE. In den Repositorien liegen vorkompilierte RPMs, die auf die Vorgaben der jeweiligen Distri optimiert sind. Ein RPM für, sagen wir, Open SuSE 10.3, dürfte auf der Basis von Standardbibliotheken aus dem Lieferumfang dieser Distri kompiliert sein, die in einem älteren SuSE gar nicht vorliegen; dadurch kann das RPM auf älteren SuSEs nicht eingesetzt werden.
Immerhin kümmert sich solche Paketmanagement-Software um Abhängigkeiten, das heißt, wenn man ein RPM darin auswählt, kann man sicher sein, dass andere RPMs, die eigentlich vorher hätten installiert werden müssen, auch vorher noch installiert werden.
Ein RPM kann mittels des Kommandozeilenprogramms rpm2targz in ein *.tar.gz-Archiv umgewandelt werden. Wenn man sich dieses anschaut, sieht man sehr schön, dass die Verzeichnisstruktur des Linux-Dateisystems, soweit relevant, darin nachgebildet ist, es gibt also z.B. ein Verzeichnis /usr mit /bin und /lib-Unterverzeichnissen etc. Wenn man den Inhalt dieser Verzeichnisse an die jeweiligen Stellen im Verzeichnisbaum von Linux kopiert, tut man genau das, was der Befehl rpm auch tut (außer, dass dieser in der Regel das Paket für Abhängigkeitsprüfungen noch in einer Datenbank registriert). Wenn man von einem Programm mal nur PRMs findet, kann man sich so manchmal behelfen.
Debian hat ein anderes Paketmanagement entwickelt, dass z.B. in Knoppix, Kanotix und Ubuntu zum Einsatz kommt: apt-get. Der Name kommt von Advanced Packaging Tool. Eigentlich ist dpkg für das Paketmanagement zuständig und apt-get ist nur ein Frontend. Dpkg-Pakete enden auf die Erweiterung *.deb. Apt-get wird in der Regel von grafischen Paketmanagern wie Synaptic, aptitude usw. verwendet.
Soweit ich weiß, liegt ein großer Vorteil gegenüber darin, dass die meisten Distris, die dieses Verfahren verwenden, direkte Ableger von einem bestimmten Debian-Zweig sind (stable oder unstable), so dass neben speziellen Paketen für die Distri auch die passenden Debian-Pakete verwendet werden können. Ansonsten sieht der Anwender vielleicht keine tiefergehenden Unterschiede, wenn er z.B. Yast mit Synaptic vergleicht. Es gibt übrigens auch apt-get-Tools für RPM auf der Basis von apt-rpm.
Auch hier gilt, dass die enthaltenen Programme vorkompiliert sind. Hauptnachteil dieses Verfahrens ist, dass der Programmierer oder der Paket-Ersteller entscheidet, welche Abhängigkeiten zu erfüllen und welche Funktionen bereitzustellen sind. Bei gimp z.B. kann man die Unterstützung von LZW-TIF beim Kompilieren einschalten, was aber wegen der möglichen Lizenzprobleme von Paket-Erstellern normalerweise nicht gemacht wird. Infolgedessen kann gimp oft mit LZW-gepackten TIF-Dateien nicht umgehen, während man diese Funktion einschalten kann, wenn man das Programm aus den Quellen selbst kompiliert.
Einen eigenen Weg geht Gentoo, dessen Protage-Paketmanagement sich ebenfalls automatisch um Abhängigkeiten kümmert, aber fast alle Programme immer aus den Quellen kompiliert und mittels auf dem Zielsystem gesetzter sogenannter USE-Flags konfiguriert. Wenn Programme z.B. eine Möglichkeit haben, das SVG-Format zu unterstützen, dieses Format aber vom Benutzer nie verwendet wird, kann er ein USE-Flag -svg setzen, das dazu führt, dass kein Programm mit SVG-Unterstützung kompiliert wird. Natürlich dauert das Kompilieren von Programmen ziemlich lange, auf jeden Fall länger als das Installieren vorkompilierter Pakete. Einige große Programme wie z.B. Firefox (das eine Menge Abhängigkeiten mitbringt) und Open Office können auch explizit als vorkompilierte bin-Pakete mit Portage installiert werden, aber das sind Ausnahmen.
Ein weiteres interessantes Verfahren für alle Linuxe ist klik (
http://klik.atekon.de). Klik ermöglicht die Installation von inklusive aller Abhängigkeiten vorkompilierten Programmen, die dann als Icon auf dem Desktop liegen und gestartet werden und durch Löschen des Icons auch wieder vollständig entfernt werden, durch einen Klick auf das Programmicon auf der Webseite. Wie klik für verschiedene Distris nachgerüstet werden kann, steht auf der genannten Seite.
Nachteile dieses Verfahrens liegen vor allem darin, dass die so installierten Programme mittels eines virtuellen Dateisystems in das Linux-Dateisystem eingeblendet werden müssen; der Kernel des Systems muss daher das Dateisystem cramfs unterstützen. Bei den meisten normalen Distris ist das der Fall, weil die Kernel da gerne mit zig Funktionen für alle Fälle kompiliert werden, auch wenn sie wohl nie eintreten. Wer seinen Kernel selbst baut, sollte an cramfs denken, wenn er klik einsetzen will.
Außerdem können nur maximal sieben Klik-Anwendungen gleichzeitig laufen, was ebenfalls in cramfs begründet liegt, aber das dürfte nur selten zu Problemen führen. Für das schnelle Ausprobieren einer Software ist klik jedenfalls sehr gut geeignet, weil das Programm einfach rückstandslos wieder entfernt werden kann, wenn es nicht gefällt.
Wenn eine Software partout nicht im Paket-Management des eigenen Systems vorhanden ist und auch keine Drittanbieter gefunden werden können, muss man ggfs. mal selbst kompilieren. Ich habe seinerzeit ein SuSE 9.1 auf diese Weise, weil neuere Software für diese Distri nicht mehr zu haben war, mit selbst kompilierten Programmen so weit aufgebohrt und modernisiert, dass später SuSE-Systemprogramme wie Sax nicht mehr liefen und RPMs keinen Sinn mehr hatten.
In den allermeisten Quellcode-Paketen liegen readme-Dateien, die erklären, wie beim Kompilieren vorzugehen ist. Meistens gilt der Dreisatz:
./configure
Dies ist ein Skript, das im Quellcode-Verzeichnis auszuführen ist und überprüft, ob alle Abhängigkeiten erfüllt sind. Wenn man den Parameter --help angibt, bekommt man eine Liste aller möglichen Parameter, sowohl der allgemeinen (wie z.B. --help) als auch der paketspezifischen. Endet dieses Skript nach einer langen Liste von Meldungen ohne abschließenden Fehler, kann der nächste Schritt erfolgen:
make
Dieser Befehl nimmt den für das System vorbereiteten Quellcode und kompiliert ihn. das kann je nach Größe des Programms und Leistung des Systems wenige Sekunden, mehrere Minuten oder ein paar Stunden dauern. Jede Menge mystisch aussehender Ausgaben scrollen über den Bildschirm, zu denen man ruhig eine wissende Miene machen kann, wenn Windows-Benutzer zusehen, auch wenn sie einem nichts sagen.
Diesen und den vorigen Schritt kann (ja, sollte) man ruhig als normaler Benutzer ausführen. Der nächste Schritt ist
make install
Diesen Schritt führt man normalerweise als Root aus, mittels su kann man ihn als Benutzer auch so ausführen:
su -c "make install"
Nach der Eingabe des Root-Passworts geht es dann weiter. Dieser Befehl installiert das Programm in die Linux-Dateistruktur, verteilt also alle Teile des Programms auf die Unterverzeichnisse wie /usr/local/bin usw. Das Programm ist aber auch ohne diesen Schritt bereits ausführbar, es kann also auch aus der im Quellcode-Verzeichnis entstandenen Struktur heraus gestartet werden (aber die liegt natürlich nicht im Pfad, deshalb muss das Programm mit vollständigem Pfad aufgerufen werden).
Meist kann man mit
make uninstall
im Quellcode-Verzeichnis das Programm auch wieder deinstallieren, sofern man die dort durch make entstandenen Strukturen unberührt lässt. Will man hingegen diese Strukturen wieder in den Ausgangszustand versetzen, benutzt man
make clean
Danach ist ein make uninstall aber nicht mehr möglich.
Das sind zwar nicht alle Möglichkeiten, um an Software zu kommen, aber die verbreitetsten und mMn interessantesten. Wer noch andere Systeme vorstellen oder das Gesagte ausweiten bzw. korrigieren will, kann das gerne tun.
Robin
Thema: [Tipp] Softwareinstallation und Paketmanagement (Gelesen 2401 mal)
