Dieses Handbuch wird mit freundlicher Genehmigung von Sebastian Hetze auf den Servern der Linux Information Systems AG gehosted.

next up previous contents index
Next: Datensicherung Up: Systemverwaltung Previous: Partitionen und Dateisysteme

Subsections


Softwaremanagement

  

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:

 

Sourcepakete
   enthalten den Quelltext für das Programm und sämtliche dazugehörenden Dateien. Jedes Sourcepaket läßt sich auf eine Release (Freigabe) von dem oder den Entwickler(n) zurückführen.

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.

Binärpakete
   enthalten ausführbare Programmdateien für eine bestimmte Rechnerarchitektur und für ein bestimmtes Betriebssystem, gemeinsam mit den zur Laufzeit benötigten Daten, Konfigurationsdateien und der Dokumentation.

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.

TAR-Archive
sind der Standard für die Verbreitung von Sourcen für Freie Software im Internet. Der Name leitet sich von Tape ARchive ab und ist Konzept. TAR-Archive können direkt auf die unterschiedlichsten Medien geschrieben oder als Dateien in jedem Dateisystem angelegt werden. Der größte Vorteil dieses Archivformats besteht in seiner Portabilität. Eine Version des Programms tar zur Bearbeitung der TAR-Archive ist praktisch für jedes Betriebssystem erhältlich. TAR-Archive können auf jedem UNIX-System (natürlich auch unter Linux) erzeugt und gelesen werden.

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.

RPM-Pakete
sind speziell für die Distribution und das damit verbundene Softwaremanagement entworfene Softwarepakete. Das Format wurde zunächst für die RedHat-Distribution entwickelt, wird aber heute von weiteren Distributoren benutzt.

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.

DEB-Pakete
   sind speziell für die Debian-Distribution gepackt. Der Aufbau dieser Pakete ist ebenfalls speziell für die Anforderungen von Distribution und Softwaremanagement entwickelt worden.

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.

Vom Sourcepaket zum fertigen Programm

      

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[*] 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.

Paketmanagement mit RPM

   

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.

Installation und Upgrade einer Software

   

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] # _

Untersuchung von RPM-Paketen

  Mit dem Query-Modus von rpm können die RPM-Pakete auch vor dem Installationsversuch untersucht werden. Die Probleme mit der Abhängigkeit von anderen Paketen können dann ebenfalls systematisch gelöst werden:

[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.

Direkter Zugriff auf die Daten in der RPM-Datei

  Um nach dem erzwungenen Upgrade auf die neue Version eine einzelne Datei aus dem Archiv des alten Pakets zu extrahieren, kann das Programm rpm2cpio   zusammen mit cpio verwendet werden.

[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.

RPM und die Konfiguration der Software

   

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.

 


next up previous contents index
Next: Datensicherung Up: Systemverwaltung Previous: Partitionen und Dateisysteme

Das Linux Anwenderhandbuch
(C) 1997 LunetIX