Next: Datensicherung Up: Systemverwaltung Previous: Partitionen und Dateisysteme
Next: Datensicherung
Up: Systemverwaltung
Previous: Partitionen und Dateisysteme
Ein Linux-System ist kein statisches Gebilde, das einmal installiert und dann nicht mehr verändert werden kann. Die große Vielfalt Freier Software und die sehr unterschiedlichen Einsatzgebiete von Linux machen Linux im Gegenteil zum flexibelsten Betriebssystem auf dem Markt. Bereits bei der Installation läßt sich die Zusammenstellung des Systems bis hinunter zur Auswahl einzelner Programme individuell anpassen.
Nach Abschluß der Erstinstallation gibt es verschiedene Möglichkeiten, neue Software zum System hinzuzufügen oder installierte Pakete wieder zu entfernen. Die modernen Linux-Distributionen kommen alle mit komfortablen Tools zur Verwaltung der Softwarepakete. In den meisten Fällen läßt sich damit das Softwaremanagement über eine einfache Menüsteuerung oder unter der grafischen Oberfläche mit der Maus durchführen.
Die Objekte, mit denen das Softwaremanagement unter Linux arbeitet,
sind sogenannte Pakete. In einem Paket sind mehrere Dateien
zusammengepackt. Gemeinsam mit den Daten ist mindestens die
Information, in welchem Verzeichnis diese Dateien installiert werden
sollen, in dem Paket enthalten. Je nach Art und Herkunft des Paketes
können zusätzlich Informationen über die Abhängigkeit dieses
Pakets von anderen Paketen, Anweisungen für die automatische
Vorbereitung der Installation und verschiedene ähnliche Metadaten
Bestandteile eines Pakets sein.
Die Pakete lassen sich nach Herkunft, Form und Inhalt in verschiedene Kategorien aufteilen:
Die Freigabe von Quelltexten für Computerprogramme hat eine lange Tradition in der UNIX-Welt. Indem Linux die gleiche Betriebssystemschnittstelle wie UNIX benutzt, können praktisch alle für UNIX entwickelten Programme auch unter Linux verwendet werden. Fast die gesamte Software, die heute mit einer Linux-Distribution ausgeliefert wird, hat ihren Ursprung in einem Sourcepaket für das traditionelle UNIX.
Ob es sich bei einer Datei um ein Sourcepaket handelt, ist von außen in der Regel nicht festzustellen. Manchmal enthält der Dateiname eines Sourcepakets den Abschnitt .src.. Möglicherweise ist auch das Gegenstück zum Sourcepaket, nämlich das Binärpaket, durch den Abschnitt.bin. gekennzeichnet, was automatisch die ansonsten gleichnamige Datei als Sourcepaket kennzeichnet. Aufgrund der UNIX-Tradition ist es sehr wahrscheinlich, daß TAR-Archive, die nicht zu einer Linux-Distribution gehören, ein Sourcepaket enthalten.
Nicht jedes Sourcepaket von UNIX läßt sich ganz ohne Anpassung für
ein Linux-System verwenden. Aus der Dynamik der frühen
Linux-Entwicklung heraus werden viele Sourcepakete in einer
speziellen Linux-Versionen neu gepackt und über bestimmte
FTP-Server verteilt (tsx-11.mit.edu und
sunsite.unc.edu).
Mit den Linux-Distributionen werden, der GNU General Public License entsprechend, ebenfalls Sourcepakete zu allen Freien Programmen ausgeliefert. Die in diesen Paketen enthaltenen Sourcen können wiederum spezifische Veränderungen des jeweiligen Distributors enthalten. Solche Änderungen sind entweder unsichtbar in den Programmtext integriert oder (zusätzlich) als DIFF-Datei dem Paket beigelegt. Diese Sourcepakete werden bei der Installation nicht auf die Festplatte kopiert. Sie befinden sich in der Regel in einem separaten Ast des Verzeichnisbaums auf der CD.
Um aus einem Sourcepaket ein ausführbares Programm zu gewinnen, muß es in der Regel in einem Seitenast des Verzeichnisbaums auf der Festplatte ausgepackt, mit Hilfe eines Compilers übersetzt und die dabei entstehenden Dateien anschließend installiert werden.
Die Verbreitung von Linux-Software in Form von Binärpaketen hat sich mit den Linux-Distributionen etabliert. Die Geschichte der Distributionen reicht von MCC-Interim über SLS und Slackware zu der gegenwärtigen Vielfalt unterschiedlicher Distributionen auf dem Markt.
Gelegentlich sind Sourcepakete durch den Abschnitt .bin. im Dateinamen gekennzeichnet. Ohne diese Kennzeichnung sind Binärpakete fast ausschließlich bei den verschiedenen Linux-Distributionen zu finden.
Mit Ausnahme einiger weniger kommerziell lizenzierter Produkte
stammen alle Binärpakete direkt von entsprechenden Sourcepaketen
ab. Die Leistung der Distributoren besteht in erster Linie darin,
die Software in ein konsistentes Dateisystemmodell einzubauen,
für eine möglichst einfache Installation zu sorgen und eine
sinnvolle Defaultkonfiguration vorzunehmen.
Durch die Verbreitung in fertigen Binärpaketen ist die Installation von Linux-Software heute ebenso einfach wie die der Produkte von Microsoft und Co. Die Programme werden durch ein einzelnes Installationskommando gebrauchsfertig eingerichtet. Selbst auf Spielereien mit grafischer Oberfläche braucht die Systemverwalterin bei der Installation von Linux-Software heute nicht mehr zu verzichten.
In TAR-Archive werden Dateien und ganze Verzeichnisbäume eingepackt. In der Regel werden diese Archive auch in dem zweiten Sinn gepackt: durch ein Kompressionsprogramm (heute in der Regel gzip) werden die im Archiv zusammengefaßten Daten verdichtet.
TAR-Archive lassen sich leicht an der typischen Endung .tar erkennen. Je nachdem, ob sie mit compress oder mit gzip komprimiert sind, kann die Endung zu tar.Z oder .tar.gz erweitert sein. Um Dateien im TAR-Format auch in einem DOS-Dateisystem speichern zu können, hat sich auch die Endung .tgz für mit gzip komprimierte TAR-Archive etabliert.
TAR-Archive werden mit dem Programm tar bearbeitet.
Zu Beginn der Entwicklungsgeschichte der Linux-Distributionen war das TAR-Format auch der Standard für die Verteilung der fertig übersetzten, binären Software. Als Pakete waren diese Archivdateien aber nur begrenzt geeignet. Es hat sozusagen an der Verpackung gefehlt. TAR-Archive haben kein reguläres Feld für Absendervermerke.
Durch die Entwicklung spezieller Paketformate, die den Anforderungen bezüglich Softwaremanagement viel besser gerecht werden, gerät das TAR-Archiv bei der Distribution von gebrauchsfertigen Softwarepaketen mehr und mehr in den Hintergrund.
Die Dateinamen der RPM-Pakete tragen typischerweise die Endung .rpm.
Als eigentliche ``Fracht'' ist in jedem RPM-Paket ein CPIO-Archiv eingepackt. In der Funktion sind CPIO-Archive den TAR-Archiven gleichwertig, sie werden jedoch mit dem Programm cpio erzeugt und verwaltet.
Mit dem CPIO-Archiv selbst hat die Systemverwalterin bei der Benutzung von RPM-Paketen in der Regel nichts zu tun. Das Archiv kann zwar unkompliziert mit Hilfe des Programms rpm2cpio extrahiert werden, der RedHat Packet Manager rpm übernimmt das Handling des Archivs aber vollständig und erledigt darüberhinaus wesentliche Aufgaben des Sofwaremanagements.
Im Unterschied zu tar gehören rpm und rpm2cpio nicht zu den Standardutilities und sind deshalb nicht automatisch in jeder Linux-Distribution enthalten. Die Nachrüstung ist nicht schwieriger als die Installation irgendeiner anderen Software. Allerdings kann ein nachträglich installiertes RPM-System nur die Software verwalten, die mit diesem System neu installiert wurde.
Auch Debian-Pakete können leicht an ihren Dateinamen erkannt werden: sie tragen die Endung .deb.
Intern sind DEB-Pakete als verschachteltes Archiv aufgebaut: die DEB-Datei ist ein AR-Archiv, darin enthalten sind zwei komprimierte TAR-Archive und eine Indikatordatei. Zum Auspacken eines DEB-Pakets sind deshalb im Notfall nur die Standardtools ar und tar erforderlich. Die volle Leistungsfähigkeit des DEB-Formats erschließt sich aber erst durch die Verwendung der Debian Pakettools dpkg und dselect.
Mit den modernen Linux-Distributionen ist die Installation eines Systems mit vielen hundert lauffähigen Programmen ein Kinderspiel. Tools wie rpm oder dselect nehmen der Systemverwalterin viel Arbeit beim Hinzufügen oder beim Entfernen von Softwarepaketen ab. Linux hat so innerhalb weniger Jahre den Ruf eines Hacker-Betriebssystems abgelegt und steigt stetig in der Gunst ``normaler'' Benutzer. Das ist sehr gut so und diese Entwicklung ist noch nicht abgeschlossen. Der schlechte Ruf von UNIX, das als kompliziert und schwer bedienbar gilt, wird von Linux nicht übernommen.
Die Möglichkeit, Freie Software als Binärpaket ohne Aufwand in kürzester Zeit installieren zu können ist eine Bereicherung. Es ist aber sowohl für den einzelnen Anwender als auch für die Zukunft von Linux allgemein wichtig, daß die gleiche Software überall auch aus den Sourcen neu erzeugt werden kann. Nur so hat jeder Anwender die Möglichkeit, Anpassungen, Fehlerkorrekturen und Verbesserungen an seinem System unabhängig durchzuführen. Die massenhafte Verbreitung der Sourcen ermöglicht die Emanzipation der Benutzer und die aktive Gestaltung und Entwicklung neuer Software nach den eigenen Bedürfnissen.
Die Faszination von Freier Software ensteht so richtig erst beim
Mitmachen. Es ist das reale Erlebnis von Freiheit![[*]](./icons/foot_motif.gif){kind=icon}
und Abenteuer: in den
unermesslichen Tiefen des Internet gibt es ständig neue Software zu
entdecken. Aus kleinen Keimen können, durch die gemeinsame
Anstrengung vieler, große Verzeichnisbäume wachsen.
Come to where the future is
Come to Linux Country
Ende der Werbepause :-)
Es gehört kein Informatikstudium und schon gar keine Zauberkraft dazu, ein UNIX-Programm unter Linux zu übersetzen. Eine Voraussetzung muß allerdings erfüllt sein: das Entwicklungssystem muß installiert sein.
Das folgende Beispiel zeigt, wie der Midnight Commander (mc) aus den originalen Sourcen erzeugt wird.
Zuerst muß das Sourcepaket per FTP geholt werden. Dazu eignet sich jeder FTP-Client. Voraussetzung ist natürlich ein funktionierender Internetanschluß.
Ohne Internetanschluß können Sourcepakete auch von einer der vielen Archiv-CDs gezogen werden, die beispielsweise im Buchhandel vertrieben werden.
[01] $ cd /usr/src
[02] $ ncftp prep.ai.mit.edu:/pub/gnu/mc-4.1.tar.gz
...
Receiving file: mc-4.1.tar.gz
mc-4.1.tar.gz: 1093859 bytes received in 216.24 seconds, 4.94 K/s.
[03] $ ls -l mc-4.1.tar.gz
-rw-rw-r-- 1 she she 1093859 Sep 17 01:40 mc-4.1.tar.gz
[04] $ _
Bei dem Softwarepaket handelt es sich um ein mit gzip komprimiertes TAR-Archiv. Diese Datei wird mit dem Programm tar bearbeitet. Das Dekomprimieren kann tar ``on the fly'' erledigen, indem es mit der Option -z aufgerufen wird.
Vor dem Auspacken ist es immer sinnvoll, zuerst ein Listing des Inhalts anzusehen. Der Aufwand für diese kurze Überprüfung steht in keinem Verhältnis zu dem Ärger, den ein schlecht gepacktes TAR-Archiv machen kann. Es kann nämlich passieren, daß das Archiv ohne Verzeichnis erzeugt wurde und deshalb alle Dateien im aktuellen Verzeichnis ausgepackt werden!
[04] $ tar tvfz mc-4.1.tar.gz
drwxr-xr-x miguel/gnu 0 1997-09-16 23:55 mc-4.1/
drwxr-xr-x miguel/gnu 0 1997-09-16 23:54 mc-4.1/src/
-rw-r--r-- miguel/gnu 2588 1997-09-16 23:54 mc-4.1/src/color.h
-rw-r--r-- miguel/gnu 1265 1997-09-16 23:54 mc-4.1/src/file.h
...
-rw-r--r-- miguel/gnu 6 1997-09-16 23:55 mc-4.1/os2/os2edit/dirtools.h
-rw-r--r-- miguel/gnu 25471 1997-09-16 23:55 mc-4.1/os2/os2edit/makefile.de
bug
-rw-r--r-- miguel/gnu 24935 1997-09-16 23:55 mc-4.1/os2/os2edit/makefile.re
lease
-rw-r--r-- miguel/gnu 95 1997-09-16 23:55 mc-4.1/os2/os2edit/makefile.rf
[05] $ _
Das Listing zeigt, daß sämtliche Dateien aus dem TAR-Archiv in das
Verzeichnis mc-4.1 installiert werden. Dieses
Verzeichnis wird beim Auspacken automatisch erzeugt.
[05] $ ^tv^x
tar xfz mc-4.1.tar.gz
[06] $ cd mc-4.1
[07] $ ls -F
COPYING README.OS2* doc/ os2/
FAQ VERSION edit/ slang/
INSTALL VERSION.in icons/ src/
INSTALL.FAST acconfig.h install-sh* tk/
Make.common.in aclocal.m4 lib/ vfs/
Makefile.in config.h.in mc.spec xv/
NEWS configure* mc.spec.in
README configure.in mcfn_install.in
README.NT* create_vcs* nt/
[08] $ _
Das Kommando in Zeile 05 gehört zur Trickkiste der bash (History Funktion). Hier wird das vorhergehende Kommando wiederholt und dabei die Buchstaben tv aus der Optionenreihe von tar durch x ersetzt.
Die erste Aktion nach dem Auspacken ist natürlich das Listing des neu erzeugten Verzeichnisses. Die Option -F sorgt für die Markierung der ausführbaren Dateien und der Verzeichnisse, das erleichtert die Orientierung.
In dem Listing sind einige Dateien mit der Endung .in zu
sehen. Zusammen mit der Datei configure ist das ein deutlicher
Hinweis darauf, daß dieses Paket mit
GNU-autoconf konfiguriert wird. Die .in-Dateien werden
durch die Konfigurationsprozedur automatisch an das lokale System
angepaßt.
Weil jedes Softwarepaket seine Eigenarten hat, ist es sinnvoll, zuerst einmal die wichtigsten Dokumente durchzusehen. Zum Lesen der Dateien eignen sich am besten Pager wie more oder less. Als erstes sollte immer die Datei README (auch Readme, Read.Me, Liesmich oder ähnlich) gelesen werden. Wenn eine frühere Version des Programms bereits bekannt ist, bieten sich die NEWS an. Als nächstes drängt sich die Datei INSTALL auf, oder, weil wir es eilig haben, besser noch INSTALL.FAST.
Außerdem zeigt das Listing von Zeile 07 ein Verzeichnis doc/, in dem sich vermutlich weitere Information zum Programm befindet.
[08] $ less README
[09] $ less INSTALL.FAST
...
1. Configure the package for your system.
Normally, you just `cd' to the package main directory and type
`./configure'.
...
2. Type `make' to compile the package.
3. Type `make install' (as root) to install programs, data files, and
documentation.
...
[10] $ ls -F doc/
DEVEL Makefile.in mc.sgml
FILES linuxdoc-sgml.diff mcedit.1
LSM mc.1 mcserv.8
[11] $ _
Der kürzeste Weg zum ausführbaren Programm ist also: ./configure eingeben, dann make und dann make install.
Das Listing des Dokumentationsverzeichnisses zeigt einige
Manualpages, die bei der späteren Installation des
Programms in ein Verzeichnis des MANPATH kopiert
werden. Die Datei mc.sgml enthält Dokumentation zum Midnight
Commander mit Formatanweisungen in der Standard Generec Markup
Language. Zum Formatieren dieses Dokuments wird ein Paket namens
linuxdoc-sgml benötigt. Die Datei linuxdoc-sgml.diff
entält eine Verbesserung für dieses Paket, die zum Formatieren von
mc.sgml benötigt wird. Mit dem Programm patch
können die Änderungen an linuxdoc-sgml automatisch
durchgeführt werden. All diese Dateien sind aber für die
Konfiguration, das Übersetzten und den Test des Programms nicht
notwendig. Für eine intensivere Beschäftigung mit den Sourcen ist
möglicherweise noch die Datei FILES interessant, in der eine
kurze Inhaltsangabe aller zum Paket gehörenden Dateien zu finden ist.
Nachdem zunächst die wichtigsten Informationen gesichtet wurden, kann mit der eigentlichen Konfigurierung des Softwarepakets begonnen werden.
[10] $ ./configure
creating cache ./config.cache
checking for prefix by ... checking for mc... /usr/local/bin/mc
checking whether make sets ${MAKE}... yes
checking for gcc... gcc
checking whether we are using GNU C... yes
...
Configuration:
Source code location: .
Compiler: gcc
Compiler flags: -g -O
File system: Midnight Commander Virtual File System
tarfs, mcfs, ftpfs
Text mode screen manager: SLang with terminfo
Install console saver: yes
Text mode mouse library: GPM and xterm
Debugger code: none
With subshell support: yes
X11 versions: none
Internal editor: yes
Install path: /usr/local/bin, /usr/local/lib/mc
[11] $ _
Diese Konfiguration ist zum Testen des neuen Programms sehr gut. Die Kombination -g -O für die Compiler Flags sorgt dafür, daß spezielle Informationen zum Debuggen in das Programm eingebaut werden (durch die Compileroption -g) und daß der Compiler das Programm einfach optimiert (durch die Compileroption -O). Als Installationspfad ist /usr/local/bin und /usr/local/lib/mc festgelegt. Diese Verzeichnisse befinden sich außerhalb des Bereiches, in dem die Linux-Distributionen ihre Programme installieren. Deshalb kann das neue Programm hier problemlos installiert werden, ohne daß die Gefahr besteht, ein bestehendes Softwarepaket zu stören.
Wäre das neue Programm fertig getestet und sollte es anstelle einer vielleicht bereits installierten früheren Version in /usr/bin installiert werden, könnte configure auch folgendermaßen aufgerufen werden:
[10] $ CFLAGS="-O2" ./configure --prefix=/usr
...
[11] $ _
Durch diese Konfigurationsvariante werden mit den CFLAGS die Compileroptionen so eingestellt, daß keine Debuginformatonen mehr in die Binärdatei eingebaut werden. Stattdessen wird der Optimierungsgrad erhöht. Außerdem wird der Installationspfad durch die Angabe eines -prefix in den Stamm des Verzeichnisbaums verlegt.
Softwarepakete, die sich nicht mit GNU-autoconf
konfigurieren lassen, müssen ``von Hand'' an das System angepaßt
werden. Wenn in den Dokumenten kein Hinweis auf die Konfiguration für
Linux zu finden ist, reicht meistens die Anlehnung an ein anderes
UNIX-Modell aus. In der Regel eignet sich System V (häufig auch
SYSV, SysV, SVR3 oder ähnliches) am
besten. Für die Anlehnung an den BSD-Stil muß eventuell die
Kompatibilitätsbibliothek libbsd.a durch die Compileroption
-lbsd hinzugelinkt werden.
Auch nach der Konfiguration mit autoconf ist es manchmal sinnvoll, kurz einen Blick in die Datei Makefile zu werfen. Möglicherweise lassen sich dort noch systemspezifische Anpassungen vornehmen.
Speziell nach der automatischen Konfiguration verschafft das Kommando 'ls -rtl' nochmal einen guten Überblick. Das Listing wird, nach der Modifikationszeit sortiert, mit der jüngsten Datei zuletzt ausgegeben. So läßt sich leicht erkennen, welche Dateien von configure erzeugt oder verändert wurden.
[11] $ ls -rtl
...
drwxr-xr-x 4 she she 1024 Sep 16 23:55 os2
-rw-rw-r-- 1 she she 5288 Oct 5 12:28 config.log
-rw-rw-r-- 1 she she 7290 Oct 5 12:28 config.cache
-rw-rw-r-- 1 she she 2850 Oct 5 12:28 Make.common
-rwxrwxr-x 1 she she 23511 Oct 5 12:28 config.status
drwxr-xr-x 2 she she 1024 Oct 5 12:28 doc
drwxr-xr-x 3 she she 1024 Oct 5 12:28 vfs
-rw-rw-r-- 1 she she 3875 Oct 5 12:28 Makefile
drwxr-xr-x 2 she she 1024 Oct 5 12:28 lib
drwxr-xr-x 3 she she 1024 Oct 5 12:28 xv
drwxr-xr-x 2 she she 1024 Oct 5 12:28 tk
drwxr-xr-x 2 she she 2048 Oct 5 12:28 src
drwxr-xr-x 2 she she 1024 Oct 5 12:28 slang
drwxr-xr-x 2 she she 1024 Oct 5 12:28 edit
drwxr-xr-x 2 she she 2048 Oct 5 12:28 icons
-rw-rw-r-- 1 she she 1877 Oct 5 12:28 mcfn_install
-rw-rw-r-- 1 she she 12733 Oct 5 12:28 config.h
[12] $ _
Die interessanteste Datei in diesem Listing ist wahrscheinlich config.h. Sollte es zu Problemen beim übersetzen des Programms kommen, ist das ein guter Ort, um mit der Suche nach der Ursache zu beginnen.
Nach all den Vorbereitungen ist es Zeit für einen ersten Versuch, das Programm zu Übersetzen.
[12] $ make
make[1]: Entering directory `/usr/src/mc-4.1/vfs'
DLIBDIR=\""/usr/local/lib/mc/"\" -DICONDIR=\""/usr/local/lib/mc/icons/"\" -D
HAVE_CONFIG_H -g -O local.c
gcc -c -I.. -I./../vfs -I./.. -I./../slang -I.. -DBINDIR=\""/usr/local/bin/"
\" -DLIBDIR=\""/usr/local/lib/mc/"\" -DICONDIR=\""/usr/local/lib/mc/icons/"\"
-DHAVE_CONFIG_H -g -O vfs.c
...
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/usr/src/mc-4.1/xv'
make[1]: Entering directory `/usr/src/mc-4.1/icons'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/usr/src/mc-4.1/icons'
[13] $ _
Ganz unspektakulär wird der Compilerlauf nach wenigen Minuten erfolgreich abgeschlossen. Genauere Erläuterung zu den während der Übersetzung ausgegebenen Meldungen gibt es bei der Dokumentation zu make und gcc.
Ein Fehler bei der Übersetzung hätte sich deutlich zu erkennen gegeben:
...
main.c: In function `do_execute':
main.c:802: `last_passed' undeclared (first use this function)
main.c:802: (Each undeclared identifier is reported only once
main.c:802: for each function it appears in.)
make[1]: *** [main.o] Error 1
make[1]: Leaving directory `/usr/src/mc-4.1/src'
make: *** [all] Error 1
[13] $ _
Wie mit einem Fehler umzugehen ist, muß von Fall zu Fall unterschiedlich entschieden werden. Hier fängt das Abenteuer an. Debugging kann so spannend sein wie ein Adventure-Game. Das schönste ist aber, daß am Ende etwas dabei herauskommt, das von vielen tausend Usern auf der realen Seite unserer virtuellen Welt benutzt werden kann.
Auch ohne die Hilfe der großartigen Entwicklungswerkzeuge grep, gdb, nm, strace oder syslogd kann der kleine Fehler oben behoben werden: last_passed muß in last_paused geändert werden, dann klappt alles.
Nachdem die Übersetzung erfolgreich abgeschlossen ist, kann die erste
Testinstallation durchgeführt werden. Eventuell kann das neue Programm
auch ohne Installation direkt aus dem Sourceverzeichnis heraus
aufgerufen werden. Im Fall des Midnight Commanders fehlen dann die
Hilfsdateien, bestimmte Funktionen werden deshalb mit entsprechenden
Fehlermeldungen abgeschlossen.
Um die Installation in /usr/local durchführen zu können, muß zunächst in eine Shell mit Superuser-Rechten gewechselt werden. Dann kann durch das Kommando 'make install' der letzte Schritt ausgeführt werden.
[13] $ su
Password:
[14] # make install
./src/xmkdir /usr/local/bin /usr/local/lib/mc
mkdir /usr/local/lib/mc
./src/xmkdir /usr/local/man/man1 /usr/local/man/man8
...
make[1]: Leaving directory `/usr/src/mc-4.1/icons'
/usr/bin/install -c -m 644 ./FAQ /usr/local/lib/mc/FAQ
/usr/bin/install -c mcfn_install /usr/local/lib/mc/bin/mcfn_install
chmod +x /usr/local/lib/mc/bin/mcfn_install
Please verify that the configuration values are correctly
set in the mc.ext file in /usr/local/lib/mc
[15] # exit
[16] $ _
Am Ende der Installation wird auf die Konfigurationsdatei mc.ext hingewiesen. Sie enthält sinnvolle Voreinstellungen, die eventuell an das lokale System angepaßt werden können/müssen.
Mit diesem letzten Schritt ist die Installation abgeschlossen. Der Weg vom Binärpaket zum ausführbaren Programm ist erfolgreich zurückgelegt. Nun folgt eine Phase intensiven Testens des Programms. Im Betrieb taucht vielleicht der eine oder andere Fehler im Programm auf. Da die Sourcen ausgepackt sind, läßt sich eine korrigierte Version sehr schnell erzeugen.
Wenn sich das Programm als stabil erweist, kann das Programm im Stamm des Verzeichnisbaums installiert und das Sourceverzeichnis mit dem Kommando 'make clean' aufgeräumt werden.
Wie der vorangegangene Abschnitt zeigt, ist die Herstellung eines Binärprogramms aus einem Sourcepaket keine unüberwindliche Hürde, wenn es darum geht, eine wesentlich verbesserte Programmversion oder gar ein ganz neues Programm zu installieren.
Es dauert aber in der Regel nur ein paar Tage, bis irgendwo im Internet aus dem Sourcepaket einer neuen Softwareversion auch die passenden Binärpakete für die verschiedenen Linux-Distributionen entstanden sind. Um ein solches Binärpaket zu bekommen, müssen Sie nicht auf die nächste Distributions-CD warten. Alle Distributoren bieten auch Updates für ihre Produkte per FTP an. Die Installation oder das Upgrade eines solchen Binärpakets ist wesentlich bequemer als die Erzeugung der gleichen Software aus den Sourcen.
Mit dem RPM-System reduziert sich der Aufwand für das Upgrade eines RPM-Pakets auf einen einzigen Aufruf des Programms rpm:
[01] # rpm -q mc
mc-3.2.1-1
[02] # rpm -U ftp.tu-clausthal.de/pub/linux/redhat/i386/mc-4.1.3-1.i386.rpm
[03] # echo $?
0
[04] # rpm -q mc
mc-4.1.3-1
[05] #
Das entscheidende Kommando steht in Zeile 02. Der Rest dient allein dem Nachweis, daß das Paket tatsächlich erneuert wurde.
Durch Verwendung der Option -i anstelle von -U würde rpm im Installationsmodus arbeiten.
Ein Upgradeversuch mit einem RPM-Binärpaket kann aber auch leicht
fehlschlagen. Der RedHat Packet Manager rpm prüft vor
Installation oder Upgrade, ob alle für das einwandfreie Funktionieren
der Software erforderlichen Services anderer Pakete bereitgestellt
werden. Solche Services sind beispielsweise die Shared Libraries für
dynamisch gelinkte Programme. Es können aber auch andere Programme
sein, die von der neuen Software im Hintergrund aufgerufen werden.
Beim Upgrade auf neue Softwareversionen kann zusätzlich das Problem auftreten, daß ein spezieller Service der alten Version von anderen Paketen benötigt wird, diese Version also nicht gelöscht werden darf. Ein Beispiel für diese Situation wird weiter unten gegeben.
Zu den häufigsten Problemen bei Installation oder Upgrade gehört das Fehlen der neuesten Version einer Shared Library. Das sieht dann so aus:
[01] # rpm -U mc-4.1.3-1.i386.rpm
failed dependencies:
libslang.so.0 is needed by mc-4.1.3-1
libncurses.so.3.0 is needed by mc-4.1.3-1
[02] # rpm -q mc
mc-3.2.1-1
[03] # _
So ein Fehler muß nicht unbedingt bedeuten, daß die Software nicht installiert werden kann. Bei den Distributionen von LST und Caldera wird jedenfalls bis zur Version 1.1 die gegenseitige Abhängigkeit der Pakete nicht berücksichtigt. Das hat zur Konsequenz, daß in der Datenbank, in der rpm normalerweise die Services der im System installierten Pakete verzeichnet, kein einziger Service eingetragen ist. Das bedeutet nicht, daß die Services nicht vorhanden sind. Es hat aber zur Folge, daß jedes Paket, das irgendeinen Service anfordert, von rpm abgewiesen wird.
In einem solchen Fall kann die Installation durch die Option -nodeps erzwungen werden:
[03] # ls /lib/libncurses.so.3.0 /usr/lib/libslang.so.0
/lib/libncurses.so.3.0 /usr/lib/libslang.so.0
[04] # rpm -U --nodeps mc-4.1.3-1.i386.rpm
[05] # rpm -q mc
mc-4.1.3-1
[06] # mc
[07] # _
[01] # rpm -q --requires -p mc-4.1.3-1.i386.rpm
/usr/bin/perl
/bin/sh
libslang.so.0
libncurses.so.3.0
libm.so.5
libgpm.so.1
libc.so.5
[02] # rpm -q --whatprovides libc.so.5
libc-5.3.12-18
[03] # rpm -q --whatprovides libncurses.so.3.0
no package provides libncurses.so.3.0
[04] # rpm -q --provides -p ncurses-4.1-3.i386.rpm
libpanel.so.4
libncurses.so.4
libmenu.so.4
libform.so.4
[06] # rpm -U ncurses-4.1-3.i386.rpm
failed dependencies:
libncurses.so.3.0 is needed by mc-4.1.3-1
[07] # _
Die Zeile 06 zeigt, wie rpm verhindert, daß eine von anderen Paketen benötigte Datei beim Upgrade eines RPM-Pakets verloren geht. Im Fall von Shared Libraries wie bei ncurses ist das nicht unbedingt die beste Lösung. Schließlich können unter Linux durchaus mehrere verschiedene Major-Versions einer Shared Library nebeneinander existieren. Insgesamt überwiegen die Vorteile des RPM-Systems aber solche Problemfälle bei weitem.
[08] # rpm -q -lv -p ncurses-1.9.9g-7.i386.rpm | grep libncurses
-rwxr-xr-x- root root 262468 Nov 26 00:33 /lib/libncurses.so.1.9.
9g
lrwxrwxrwx- root root 20 Nov 26 00:34 /lib/libncurses.so.2.0
-> libncurses.so.1.9.9g
lrwxrwxrwx- root root 20 Nov 26 00:34 /lib/libncurses.so.3.0
-> libncurses.so.1.9.9g
lrwxrwxrwx- root root 20 Nov 26 00:33 /lib/libncurses.so.3.2
-> libncurses.so.1.9.9g
[09] # rpm2cpio ncurses-1.9.9g-7.i386.rpm | cpio -id ``lib/libncurses.so.*''
[10] # cp lib/* /lib
[11] # ldconfig
[12] # _
Die Scriptdateien für Vorbereitung und Abschluß der Installation bzw. Löschung werden im Query-Modus durch die Option -scripts ausgegeben.
Bei vielen Softwarepaketen ist über die eigentliche Installation hinaus noch eine systemspezifische Anpassung notwendig. Dazu werden in der Regel Einträge in Konfigurationsdateien erzeugt oder verändert.
Vor und nach dem Auspacken der Paketdaten führt rpm Shellscripts aus, die gewisse Konfigurationsarbeiten automatisch durchführen können. Andere Systemeinstellungen müssen von der Systemverwalterin ``manuell'' vorgenommen werden.
Voraussetzung für die Durchführung dieser Arbeit ist natürlich die Kenntnis, welches die Konfigurationsdateien sind und wo sie sich befinden. rpm kann diese Identifikation sehr leicht vornehmen. Außerdem kann es die zu einer Software gehörende Dokumentation ausfindig machen. Für beide Dienste muß rpm im Query-Modus arbeiten:
[01] # rpm -q -c sendmail
/etc/aliases
/etc/aliases.db
/etc/rc.d/init.d/mta
/etc/sendmail.cf
/etc/sendmail.cw
/etc/sysconfig/daemons/mta
[02] # rpm -q -d sendmail
/usr/man/man1/mailq.1.gz
/usr/man/man1/newaliases.1.gz
/usr/man/man5/aliases.5.gz
/usr/man/man8/makemap.8.gz
/usr/man/man8/rmail.8.gz
/usr/man/man8/sendmail.8.gz
[03] # _
Diese Hilfestellung ist zwar nur ein kleiner, möglicherweise aber wesentlicher Schritt zur erfolgreichen Integration einer Software in ein bestehendes System.
Ist ein Softwarepaket einmal installiert und konfiguriert, bewahrt
rpm die systemspezifischen Anpassungen auch beim Upgrade
auf eine neuer Version der Software, sogar beim Löschen eines Pakets
läßt das Programm alle veränderten Konfiguratinonsdateien zurück. Die
gesicherten Dateien haben die Endung .rpmsave und liegen im
gleichen Verzeichnis, in dem auch die Konfigurationsdate gelegen hat.
Das Linux Anwenderhandbuch