9.2 Softwareinstallation 

Die nachträgliche Installation von Softwarepaketen sowie regelmäßige Updates des bereits installierten Systems sind ein zentraler Bestandteil der Administration und werden hier daher auch mit einem eigenen Abschnitt gewürdigt.

Bevor wir uns mit der Thematik »Paketverwaltung« genauer befassen, sollten wir noch einmal klären, was Pakete (engl. Packages) genau sind. Ein Paket enthält vereinfacht gesagt eine Software, etwa den vi-Editor. Dazu zählt allerdings mehr als nur eine Datei – ein Paket beinhaltet die ausführbare Programmdatei (oder ein Skript), Manpages, zusätzliche Dokumentationen (die zum Beispiel im HTML-Format oder als TeX-Datei vorliegen), vorgefertigte Konfigurationsdateien und vielleicht auch Skripte um die Software zu starten und zu beenden. <Solche Start-Skripte finden sich in der Regel im Verzeichnis /etc/init.d oder /etc/rc.d und werden meist für Dienste verwendet, die permanent laufen und beim Systemstart automatisch gestartet werden sollen.>

Bei Ports wird die Software hingegen erst aus dem Quellcode kompiliert, doch dazu später mehr. Bei einem Port werden die Binärdateien also nicht mitgeliefert, sondern erst generiert.

Ein Paket oder Port muss aber nicht immer eine Software – und damit ein Skript oder eine Programmdatei – enthalten.

Typische Beispiele hierfür sind etwa Dokumentationspakete, die nur Dokumentationsdateien enthalten. Unter Slackware und Hardened Linux gibt es hingegen Pakete, die nur einzelne Spezialdateien enthalten. Hierzu zählen aaa_base, das den Standardverzeichnisbaum (dazu zählen in diesem Fall Verzeichnisse wie /etc, /root, /var, /usr, /sbin und auch Unterverzeichnisse wie /usr/doc oder /var/log) beinhaltet.

Unter Hardened Linux habe ich hingegen das aaa_hl-Paket eingefügt, dass nur die Datei hardenedlinux-version enthält, über die Skripte und Programme die jeweilige installierte Distributionsversion herausbekommen können. <Unter Slackware-Linux existiert ebenfalls eine solche Datei mit dem Namen slackware-version. Beide Dateien befinden sich in /etc.>

Zudem kann eine Software auch aus mehreren Paketen bestehen. Der Apache-Webserver ist bei einigen Distributionen beispielsweise in die Webserversoftware und die zugehörige Administrationssoftware aufgeteilt, sodass man zwei oder noch mehr Pakete installieren muss, um »alles, was dazu gehört« zu bekommen. Die Entscheidung über den Inhalt eines Packages trifft dabei der jeweilige Package-Maintainer (das ist die Person, die sich um ein Paket kümmert) oder sogar der Distributor selbst.

Pakete werden nicht als einfache Dateien, sondern als komprimierte Archive, bereit gestellt. Dafür gibt es mindestens zwei Gründe.

9.2.1 Paketverwaltung und Ports 

Ein effizientes Mittel, um häufige Änderungen an den installierten Programmpaketen vorzunehmen und trotzdem ein sauberes System zu behalten, ist das Paketmanagement.

Der Begriff Paketmanagement bezeichnet eine Software, die die Installation, Aktualisierung und Löschung von Paketen zentral verwaltet.

Die angesprochenen Pakete sind dabei Sammlungen der eigentlichen binären Programmdateien sowie von Konfigurations- und Datenfiles. Zu einem Paket gehören dabei immer auch Metadaten:

• Welche weiteren Softwarepakete (Abhängigkeiten) werden benötigt, damit das Paket läuft?

• Welche Arbeiten (Skripts) sind auszuführen, wenn das Paket installiert/aktualisiert/gelöscht werden soll?

• Wie heißt das Paket, in welcher Version liegt es vor? Dazu kommen weitere Informationen wie beispielsweise Kurzbeschreibungen, Schlagwörter etc. über das Paket.

Unterschiedliche Standards

Je nachdem, wie die Pakete und die Paketverwaltung organisiert sind, spricht man von unterschiedlichen Paketsystemen. Die bekanntesten aus der Linux-Welt sind wirklich paketbasierte Systeme wie das deb-Format von Debian oder RPM von RedHat beziehungsweise SuSE. Diese Pakete sind eigentlich nichts weiter als normale Archive <Als Archiv bezeichnet man eine gepackte Datei.> mit einer festen Struktur. Diese Struktur kann zum Beispiel so aussehen, dass es bestimmte reservierte Dateinamen für Metadaten oder Skripts gibt, die jeweils beim Installieren, Updaten oder Löschen ausgeführt werden.

Die Pakete werden dann schließlich entweder im Internet oder auch auf CD zu sogenannten Repositories – also zu einer Art von Verzeichnissen <Repositories sind Verzeichnisse mit Paketen samt diverser Metadaten.> – zusammengefasst, auf die dann Programme wie APT (»Advanced Packaging Tool«) zugreifen können, um die Pakete zu laden.

Ports

Einen anderen Weg, mit entsprechenden Metadaten umzugehen, haben die BSD-Systeme mit den sogenannten Ports gewählt. Ursprünglich waren die Ports eine Sammlung von Makefiles, die Targets für das Herunterladen, Auspacken, Kompilieren und Installieren der entsprechenden Softwarepakete besaßen. Jedoch können auch andere Skriptsprachen wie beispielsweise Python bei Gentoo Linux (der einzigen Linux-Distribution mit einem portsähnlichen System) oder TCL bei Darwin (MacOS) verwendet werden.

9.2.2 APT – Advanced Packaging Tool 

Stellvertretend für RPM- und DEB-basierte Systeme soll hier die Paketverwaltung mittels APT besprochen werden. Auch wenn dieses System mittlerweile auch für SuSE und andere RPM-basierte Systeme existiert, so kommt es ursprünglich doch aus der Debian-Welt. Aus diesem Grund wollen wir in Beispielen auch auf Debian eingehen. Die Beispiele lassen sich in jedem Fall jedoch ohne große Änderungen auch auf RPM-basierte Systeme übertragen.

Die sources.list

Welches Repository?

In der /etc/apt/sources.list kann man zuerst einmal die Repositories festlegen. Die Repositories können sowohl im Internet liegen als auch lokal auf Datenträgern wie CD-ROMs oder DVDs abgelegt sein. Dabei spielt es keine Rolle, ob auf die Server via HTTP oder FTP zugegriffen werden soll oder wie viele unterschiedliche Repositories definiert wurden.

Betrachten wir also eine mögliche sources.list:

# debian unstable 
deb http://ftp.de.debian.org/debian/ unstable main 
  non-free contrib 
deb-src http://ftp.de.debian.org/debian/ unstable 
  main non-free contrib 
 
# Multimedia 
deb ftp://ftp.nerim.net/debian-marillat/ unstable main

Listing 9.17    Eine beispielhafte sources.list

In diesem Beispiel wurden zwei Repositories definiert: zum einen der Server ftp.de.debian.org, von dem Binär- und Quellpakete (»deb« vs. »deb-src«) geladen werden können, und zum anderen der Rechner ftp.nerim.net, von dem offensichtlich nur Binärpakete geladen werden sollen. Die weiteren Argumente bezeichnen eigentlich nur die genaue Verzeichnisstruktur auf dem Server, von dem die Paketlisten geladen werden sollen. So hat das Verzeichnis dists/unstable auf dem ersten Server drei Unterverzeichnisse: main, non-free und contrib. Jedes dieser Unterverzeichnisse enthält nun eine Datei Packages, die die Informationen sowie den Speicherort der entsprechenden Pakete dieser Sektion enthält.

apt-get

Auf diese Repositories kann man nun zum Beispiel über das Kommandozeilenprogramm apt-get zugreifen. Die wichtigsten Optionen lauten dabei wie folgt:

• update

• Mit dem Befehl apt-get update werden die aktuellen Paketdaten von den in der sources.list angegebenen Repositories geladen. Vor allem bei Quellen im Internet und vor jedem upgrade oder dist-upgrade ist dieser Schritt zu empfehlen.

• upgrade

• Mit dieser Option werden die installierten Pakete aktualisiert. Jedoch werden unter keinen Umständen Pakete gelöscht oder neue Pakete installiert. Mit anderen Worten führt ein apt-get upgrade ein »sicheres« Upgrade durch.

• dist-upgrade

• Einen etwas schlaueren Upgrade-Mechanismus setzt apt-get dist-upgrade ein. Hier wird nämlich versucht, mit Abhängigkeiten korrekt umzugehen, die sich durch neue Paketversionen ändern. So können zum Beispiel nicht mehr benötigte Pakete gelöscht oder in der aktualisierten Version neu hinzugekommene Abhängigkeiten durch neu zu installierende Pakete gelöst werden.

• install <Paket>

Pakete installieren!

• Mit dieser Option kann man ein neues Paket installieren. Die Abhängigkeiten werden dabei automatisch bestimmt und die entsprechenden Pakete auch nach einer kurzen Nachfrage mitinstalliert.

• remove (--purge) <Paket> … <Paket>+

• Das Gegenstück zu install ist natürlich remove. Möchte man nun ein oder mehrere Pakete installieren, kann man sich jedoch noch entscheiden, ob die Konfigurationsdateien der Programme ebenfalls mit gelöscht werden sollen -- die zusätzliche Option --purge aktiviert dieses Feature.

• Möchte man gleichzeitig Pakete löschen und andere installieren, so muss man beim remove nur ein »+« an die zu installierenden Pakete anhängen. So kann man dann das Problem lösen, dass man eines von zwei sich gegenseitig ausschließenden Paketen installiert hat, man zum anderen wechseln möchte, aber aufgrund von vielfältigen Abhängigkeiten immer eines der beiden installiert sein muss. Man möchte es nicht glauben, aber so was kommt durchaus vor.

• Sehen wir uns nun eine beispielhafte Deinstallation an:

# apt-get remove --purge xmame-x 
Paketlisten werden gelesen... Fertig 
Abhängigkeitsbaum wird aufgebaut... Fertig 
Die folgenden Pakete werden ENTFERNT: 
  xmame-common* xmame-x* 
0 aktualisiert, 0 neu installiert, 2 zu entfernen 
  und 0 nicht aktualisiert. 
Es müssen 0B Archive geholt werden. 
Nach dem Auspacken werden 43,4MB Plattenplatz 
  freigegeben sein. 
Möchten Sie fortfahren? [J/n] 
(Lese Datenbank ... 16302 Dateien und Verzeichnisse 
  sind derzeit installiert.) 
Entferne xmame-x ... 
Lösche Konfigurationsdateien von xmame-x ... 
Entferne xmame-common ... 
Lösche Konfigurationsdateien von xmame-common ...

Listing 9.18    Das Paket xmame-x deinstallieren

• Bei diesem Beispiel fällt das intelligente Abhängigkeitsmanagement ins Auge: Müssen Pakete nur installiert werden, um bestimmte Abhängigkeiten zu erfüllen, so können sie getrost gelöscht werden, sollten diese Abhängigkeiten nicht mehr bestehen – wie hier im Beispiel mit dem Paket xmame-common, was nun nach der Deinstallation von xmame-x nicht mehr benötigt und daher auch gelöscht wird.

• source <Paket>

• Diese Option holt nun ein Quellpaket von einem der mit deb-src bezeichneten Repositories. Das Paket wird heruntergeladen und im aktuellen Verzeichnis als .tar.gz-Archiv gespeichert. Zu bemerken bleibt noch, dass sich normale Repositories (»deb«) von Source-Repositories (»deb-src«) unterscheiden und so ein Sourcepaket nicht immer in derselben Version wie ein Binärpaket verfügbar sein muss. Auch ist es wichtig zu wissen, dass die Installation eines Sourcepakets nicht weiter gespeichert wird.

• Ein solches entpacktes Sourcepaket kann man schließlich unter Debian mit dpkg-buildpackage übersetzen. Damit das Programm weiß, was es tun soll, liest es die in jedem Debian-Sourcepaket vorhandene Datei debian/rules aus. Möchte man also die Installationsoptionen verändern – was meistens der Grund für das Heranziehen eines Sourcepaketes ist --, so muss man diese Datei entsprechend ändern und anschließend dpkg-buildpackage aufrufen, das eine .deb-Datei mit dem eben übersetzten Programm enthält. Dieses Paket kann mittels dpkg -i <Paket-Datei> wiederum sauber ins System installiert und später über apt-get remove <Paket> auch wieder sauber deinstalliert werden.

• build-dep <Paket>

• Diese Option ist sehr nützlich, wenn man mittels apt-get source <Paket> ein Quellpaket geladen hat und diese Sourcen nun übersetzen will. Mit der Option build-dep werden nämlich alle für das Übersetzen des Quellpaketes »<Paket>« benötigten Pakete installiert.

• clean

Cache leeren

• Diese Option löscht schließlich den Paketcache unter /var/cache/apt/archives/ sowie /var/cache/apt/archives/partial/. Alle heruntergeladenen Pakete werden dort nämlich gespeichert, sodass man zum Beispiel nach einem Update auch problemlos auf die alte Version zurückgehen kann, die vielleicht nicht mehr auf dem Internet-Repository zu finden ist.

Anscheinend kann man mit apt-get bereits fast die gesamte Paketverwaltung auf einfache Weise von der Kommandozeile aus organisieren. Aber natürlich kann man alle verfügbaren Pakete durchsuchen und sich gegebenenfalls die Details der potenziell zu installierenden Pakete anzeigen lassen.

apt-cache

Zum Suchen nutzt man das Programm apt-cache mit dem Parameter »search«, gefolgt vom Suchbegriff. Möchte man also nach Paketen zum Programm xchat suchen, so wird man folgenden Befehl nutzen:

$ apt-cache search xchat 
xchat – IRC client for X similar to AmIRC 
xchat-common – Common files for X-Chat 
xchat-systray – xchat systray notification icon 
xchat-text – IRC client for console similar to AmIRC

Listing 9.19    Pakete suchen mit apt-cache

Die Details eines bestimmten Paketes kann man sich schließlich mit dem Parameter »show« anzeigen lassen:

$ apt-cache show exim 
Package: exim 
Priority: extra 
Section: mail 
Installed-Size: 1400 
Maintainer: Mark Baker <mark@mnb.org.uk> 
Architecture: i386 
Version: 3.36-17 
Replaces: mail-transport-agent 
Provides: mail-transport-agent 
Depends: libc6 (>= 2.3.2.ds1-4), libdb3 (>= 3.2.9-20), 
 libident (>= 0.22-1), libldap2 (>= 2.1.17), libpam0g 
 (>= 0.76), libpcre3 (>= 4.5), cron (>= 3.0pl1-42) 
Recommends: netbase 
Suggests: mail-reader, eximon 
Conflicts: mail-transport-agent, exim-doc-html 
 (<= 3.00-2), suidregister (<< 0.50) 
Filename: pool/main/e/exim/exim_3.36-17_i386.deb 
Size: 759024 
MD5sum: 9e796f3e4155e193b41c6720fef71785 
Description: An MTA (Mail Transport Agent) 
 This MTA is rather easier to configure than smail or 
 sendmail. It is a drop-in replacement for sendmail/ 
 mailq/rsmtp. Advanced features include the ability to 
 reject connections from known spam sites, and an 
 extremely efficient queue processing algorithm.

Listing 9.20    Paketdetails für »exim«

Offline verfügbar

Beachten Sie dabei, dass alle diese Informationen aus der Packages-Datei des Repositorys stammen. Das Paket muss also weder installiert sein noch heruntergeladen werden, um diese Suche durchführen zu können. Aber betrachten wir die wichtigsten der bereitgestellten Informationen:

• Version

• Die Version ist vor allem für den Update-Mechanismus wichtig: Gibt es nämlich eine neuere Version auf dem Repository, als gerade installiert ist, so kann man das System upgraden, indem man die neue Version installiert. Außerdem ist die Version wichtig, um die Abhängigkeiten zu managen: Manche Pakete setzen andere Pakete in einer bestimmten Version voraus.

• Provides

• Dieses Schlüsselwort gibt an, welches virtuelle Paket vom betrachteten Paket bereitgestellt wird. So wird zum Beispiel unterschieden, welcher Dienst (z. B. »mail-transport-agent«, das virtuelle Paket) von welcher Software genau (z. B. »exim«, dem betrachteten Paket) bereitgestellt wird. Ein virtuelles Paket hat den Zweck, dass andere Pakete von ihm abhängen können, aber der Benutzer noch entscheiden kann, welche Software er zur Implementierung dieses speziellen Dienstes einsetzen möchte.

• Depends

• Dieses Feld gibt die Abhängigkeiten in Paketnamen an. Sofern notwendig, wird in Klammern hinter dem Paketnamen angegeben, welche Version genau (»=«) oder mindestens (»>=«) vorausgesetzt wird.

• Suggests

• Diese Pakete werden vom betrachteten Paket vorgeschlagen. Im Regelfall werden diese Pakete jedoch nicht automatisch mit dem betrachteten Paket installiert.

• Conflicts

• Diese Pakete können nicht gleichzeitig mit dem betrachteten Paket installiert werden. In unserem Beispiel liegt ein Konflikt mit anderen Paketen vor, die ebenfalls mail-transport-agent bereitstellen. Mit anderen Worten kann man immer nur einen MTA installieren.

• Filename

• Hier kann das Paket auf dem Repository gefunden werden.

• MD5sum

• Die Prüfsumme des Pakets. Anhand dieser können eventuelle Veränderungen festgestellt werden.

• Description

• Der letzte Punkt beinhaltet schließlich eine kurze Beschreibung des Pakets. Hier erfahren wir, dass exim also eine Art Mailserver (MTA, Mail Transport Agent) ist.

SuSE & Co.

Auch wenn die Paketverwaltung mittels APT hier anhand des DEB-Formats von Debian erklärt wurde, haben Sie trotzdem auch das RPM-Format von SuSE und Redhat (beziehungsweise Fedora) verstanden: Dieses Format funktioniert nämlich fast genauso. Die unterschiedlichen Paketformate sind historisch gewachsen und wurden sich mit der Zeit immer ähnlicher. Mit dem APT-Frontend hat man nun auch die Möglichkeit, die Paketverwaltung einheitlich zu managen, egal welches Paketformat letztendlich dahinter steht – und das ist auch der Grund für die ausführliche Vorstellung dieses Frontends.

aptitude

Nun sind Konsolen-Tools nicht jedermanns Sache. Mit aptitude steht aber ein übersichtlicheres Frontend für die Konsole bereit, das viele Aufgaben erleichtert und alles unter einem Dach zusammenfasst.

Textinterface

Die Funktionalität entspricht dabei der von apt-get, mit dem einzigen Unterschied, dass bestimmte Aktionen nicht über Kommandozeilenparameter, sondern eben über Tastenkürzel ausgeführt werden. Eine Liste aller Tastenkürzel kann man sich durch die Eingabe des Fragezeichens »?« anzeigen lassen. Im Regelfall beginnt man eine aptitude-Sitzung mit einem update. Dazu drückt man die Taste »u«, worauf aptitude mit dem Herunterladen der aktuellen Repository-Daten beginnt:

Abbildung 9.1    Das Repository updaten

Ready ...

Darauf kann man schließlich im aptitude-Startbildschirm einen zusätzlichen Eintrag mit einer Liste aller aktualisierbaren Pakete sehen. In einer solchen Sektion navigiert man schließlich recht intuitiv: Durch Drücken der Enter-Taste öffnet man eine Sektion, die wie ein Verzeichnis auf einer Festplatte entweder wieder Untersektionen oder eben eine Reihe von Paketen enthalten kann. Ansonsten funktionieren die Cursortasten wie zu erwarten, und ein Enter auf eine Datei öffnet eine Detailansicht, aus der man mit einem Druck auf »q« wieder herausspringt. Drückt man »q« auf dem Startbildschirm, wird man gefragt, ob man das Programm beenden möchte.

... Set ...

Bei einem Paket hat man folgende Möglichkeiten: Man kann das Paket zum Installieren (durch Drücken von »+«), Deinstallieren (»-«), Updaten (ebenfalls »+«) und Purgen <Deinstallieren mit Löschen aller Konfigurationsdateien, also das Äquivalent zu apt-get remove --purge Paket.> (»_«) markieren. Alternativ kann man auch gleich alle aktualisierbaren Pakete durch Drücken der Taste »U« zum Upgraden auswählen beziehungsweise sogar in den Optionen festlegen, dass dies automatisch geschehen soll.

Als Ergebnis sieht man schließlich in der Statusleiste eine Zusammenfassung aller Platzangaben. Sie können dort ablesen, wie sich der Plattenplatz verändern sowie wie viel heruntergeladen werden muss:

Abbildung 9.2    Der aptitude-Startbildschirm

... Go!

Alle markierten Aktionen führt man schließlich über die Taste »g« (für »go«) aus. Infolgedessen sieht man nun noch einmal eine Liste aller vorzunehmenden Aktionen. Diese bestätigt man durch nochmaliges Drücken der Taste »g«.

Danach beginnt der Download, gefolgt von der Installation aller heruntergeladenen Pakete. Eventuell wird man dabei, wie von apt-get gewohnt, zu manchen Konfigurationsdetails gefragt.

Abbildung 9.3    Durchzuführende Aktionen

Hier ist, wie in der Paketliste auch, vor allem der Zustand interessant, der durch das vor jedem Paketnamen stehene Buchstabentripel angegeben wird. Der erste Buchstabe bezeichnet dabei den aktuellen Status: i steht für installierte Pakete, p für noch nicht installierte Pakete und c für früher einmal installierte Pakete, von denen noch die Konfigurationsdateien im System vorhanden sind.

Der nächste Buchstabe gibt den Status nach dem Durchführen der gewünschten Aktion an: Bei einem i soll das Paket installiert werden, ein d zeigt eine Deinstallation an, p ein Purge und u ein Upgrade eines bereits installierten Pakets.

Der optionale dritte Buchstabe zeigt nun besondere Eigenschaften von Paketen an: Ein großes »A« deutet zum Beispiel an, dass ein Paket automatisch installiert wurde. Sobald dieses Paket nun nicht mehr durch irgendwelche Abhängigkeiten benötigt wird, wird es automatisch deinstalliert. Der Administrator kann nun ein Paket im Nachhinein auch mit »M« als automatisch installiert markieren beziehungsweise mit einem Druck auf die Taste »m« diese Markierung wieder aufheben.

Pakete zurückhalten

Auch kann man Pakete mittels »=« von einem automatischen Update ausschließen. Entsprechende Pakete sind dann mit einem h für »hold« markiert.

Als letzter Hinweis sei hier noch die Syntax zum Suchen von bestimmten Paketen erläutert: Wie von anderen Programmen wie less gewohnt, erreicht man eine Suchmaske durch Eingabe eines Slashs (»/«). Dort kann man den Suchbegriff schließlich angeben und nach einer Bestätigung das Wort schließlich suchen lassen. Im Suchbegriff gibt es nun zwei besondere Zeichen: »^ « bezeichnet den Anfang des Paketnamens, und »$« entsprechend das Ende.

So sucht man nach der Eingabe von »test« nach allen Paketen mit dem Namensbestandteil »test« im Namen, während eine Eingabe von »^test$« nur das Paket mit dem genauen Namen »test« findet.

Distributions- spezifische Tools

Wenn man aptitude verstanden hat, so wird man auch die Funktionsweise von anderen, vielleicht distributionsspezifischen Programmen zur Paketverwaltung verstehen. Für SuSE Linux ist hier vor allem YOU – das Yast Online Update – erwähnenswert, das ähnlich wie aptitude auf ein Repository zugreift und nach aktualisierbaren Paketen sucht.

9.2.3 Pakete in Handarbeit: dpkg und rpm 

Manchmal ist die Welt leider nicht so einfach, wie man sie sich mit aptitude oder apt-get ausmalt. Einfaches Herunterladen, Installieren und Konfigurieren in einem Schritt ist zum Beispiel nicht möglich, wenn es sich um ein Paket handelt, das nicht im Repository vorhanden ist, und man die Paketdatei selbst per Hand von einer ominösen Seite heruntergeladen hat. Zwei Programme, um solche Probleme zu lösen, sind dpkg und rpm. Diese Paketmanager sitzen sozusagen eine Abstraktionsebene tiefer als das prinzipiell formatunabhängige APT-System. Aus diesem Grund müssen wir an dieser Stelle auch zwischen Debian-ähnlichen beziehungsweise -basierten Distributionen wie natürlich Debian selbst mit dem DEB-System und den RedHat-ähnlichen Distributionen wie Fedora oder SuSE mit dem RPM-System unterscheiden.

dpkg

Beginnen wir mit dem dpkg-Programm. Bei der Beschreibung von apt-get wurde bereits das Tool dpkg-buildpackage erwähnt, mit dem man heruntergeladene Sourcepakete wieder zu einem eventuell personalisierten Paket übersetzen lassen kann. Mit dpkg und seinen Freunden lässt sich also viel anstellen, jedoch soll die vordergründige Frage hier erst einmal sein: Was kann dpkg, was APT nicht kann?

Dazu wollen wir die wichtigsten Kommandozeilenoptionen betrachten, mit denen man dpkg in Ergänzung zu APT gut nutzen kann:

• -i <Dateiname>

• Möchte man eine heruntergeladene Paketdatei installieren, so wird man dpkg mit dem Parameter »-i«, gefolgt vom entsprechenden Dateinamen, aufrufen:

# cd Downloads 
# dpkg -i vim_4.5-3.deb 
…

Listing 9.21    Ein heruntergeladenes DEB-Paket installieren

• Gelöscht werden kann das Paket dann wie gewohnt mit apt-get oder aptitude. Zu beachten ist jedoch, dass man diese Tools nicht mit dem Datei-, sondern nur mit dem Paketnamen aufruft, da dieser bereits eindeutig ist. Das Beispielpaket könnte man also mit »apt-get remove vim« wieder deinstallieren.

• -l

• Möchte man eine Auflistung über alle installierten Dateien haben, so kann man diese zwar auch in aptitude betrachten, einfacher ist jedoch oft ein »dpkg -l«, in dessen Ausgabe natürlich auch ge-grept werden kann:

$ dpkg -l | grep vim 
rc kvim       6.3  Vi IMproved – KDE 3.x version 
ii vim        6.3  Vi IMproved – enhanced vi editor 
ii vim-common 6.3  Vi IMproved – Common files 
ii vim-gtk    6.3  Vi IMproved – GTK2 Version

Listing 9.22    Alle installierten »vim«-Pakete anzeigen

• Als Ausgabe erhält man hier alle Pakete mit dem Namensbestandteil »vim«.

• -L Paket

• Dagegen zeigt ein »-L«, gefolgt vom Paketnamen, den Inhalt eines Pakets und somit alle installierten Dateien an:

$ dpkg -L tuxracer 
/. 
/usr 
/usr/games 
/usr/games/tuxracer 
/usr/share 
/usr/share/doc 
/usr/share/doc/tuxracer 
/usr/share/doc/tuxracer/README.Debian 
/usr/share/doc/tuxracer/copyright 
/usr/share/doc/tuxracer/changelog.Debian.gz

Listing 9.23    Der Inhalt des Pakets »tuxracer«

• Oft möchte man nämlich wissen, was man eigentlich gerade installiert hat und wo entsprechende Dateien zu finden sind. Vor allem proprietäre, also von kommerziellen Anbietern bereitgestellte Pakete halten sich oft nicht an das unter Linux/Unix übliche Verzeichnisschema. Da werden ausführbare Dateien schon mal statt nach /usr/bin/ nach /usr/firma/programm installiert, sodass die entsprechenden Executables nicht wie vielleicht erwartet im PATH zu finden sind.

Das »letzte Geheimnis« ist nun die bereits angesprochene Installation eines Sourcepakets nach einer Übersetzung der mit »apt-get source« geladenen Sourcen. Um zum Beispiel das Paket »bash« aus den Sourcen zu installieren, muss man das Paket wie bereits erwähnt per apt-get laden:

$ apt-get source bash 
Paketlisten werden gelesen... Fertig 
Abhängigkeitsbaum wird aufgebaut... Fertig 
Es müssen 2606kB der Quellarchive geholt werden. 
Hole:1 http://ftp.de.debian.org unstable/main bash 
  3.0-15 (dsc) [725B] 
Hole:2 http://ftp.de.debian.org unstable/main bash 
  3.0-15 (tar) [2417kB] 
Hole:3 http://ftp.de.debian.org unstable/main bash 
  3.0-15 (diff) [188kB] 
Es wurden 2606kB in 11s geholt (233kB/s) 
dpkg-source: extracting bash in bash-3.0 
$

Listing 9.24    Die bash-Sourcen installieren

Das geladene Archiv wurde nach dem Herunterladen gleich entpackt. Doch bevor wir die Sourcen übersetzen, wollen wir alle Pakete installieren, die zum Übersetzen des Pakets notwendig sind. In unserem Fall handelt es sich dabei um die drei Pakete »automake«, »build-essential« und »texi2html«:

# apt-get build-dep bash 
Paketlisten werden gelesen... Fertig 
Abhängigkeitsbaum wird aufgebaut... Fertig 
Die folgenden NEUEN Pakete werden installiert: 
  automake1.8 build-essential texi2html 
0 aktualisiert, 3 neu installiert, 0 zu entfernen und 
  0 nicht aktualisiert. 
Es müssen 555kB Archive geholt werden. 
Nach dem Auspacken werden 2040kB Plattenplatz 
  zusätzlich benutzt. 
Möchten Sie fortfahren? [J/n] 
Hole:1 http://ftp.de.debian.org unstable/main 
  automake1.8 1.8.5 [454kB] 
Hole:2 ... 
... 
Es wurden 555kB in 2s geholt (204kB/s) 
Wähle vormals abgewähltes Paket automake1.8. 
(Lese Datenbank ... 160324 Dateien und Verzeichnisse 
  sind derzeit installiert.) 
Entpacke automake1.8 (aus automake1.8_1.8.5_all.deb) 
Wähle vormals abgewähltes Paket build-essential. 
... 
Richte automake1.8 ein (1.8.5) ... 
 
Richte build-essential ein (10.1) ... 
Richte texi2html ein (1.66-1.2) ...

Listing 9.25    Die build-Dependencies installieren

Das Paket selbst kann nur als root oder mithilfe des fakeroot-Tools übersetzt und gebaut werden:

$ su 
Password: 
# cd bash-3.0 
# dpkg-buildpackage 
dpkg-buildpackage: source package is bash 
dpkg-buildpackage: source version is 3.0-15 
dpkg-buildpackage: source maintainer is Matthias 
  Klose <doko@debian.org> 
dpkg-buildpackage: host architecture is i386 
 debian/rules clean 
dh_testdir 
dh_testroot 
... 
dh_gencontrol -pbash-minimal 
dh_md5sums -pbash-minimal 
dh_builddeb -pbash-minimal 
dpkg-deb: baue Paket »bash-minimal« in 
  »../bash-minimal_3.0-15_i386.deb«. 
#

Listing 9.26    Das Paket als root bauen

Schließlich kann man die gebauten Pakete betrachten und per dpkg installieren:

# ls ../bash*.deb 
../bash_3.0-15_i386.deb 
../bash-minimal_3.0-15_i386.deb 
../bash-builtins_3.0-15_i386.deb 
../bash-static_3.0-15_i386.deb 
../bash-doc_3.0-15_all.deb 
# dpkg -i ../bash_3.0-15_i386.deb 
...

Listing 9.27    Das Resultat installieren

rpm

Die Pakete des RedHat-Paketsystems haben die Endung .rpm und ähnlich komplizierte Namen wie die des Debian-Paketsystems. Im Prinzip sind aber auch RPM-Dateien wie ihre Debian-Äquivalente nur gepackte Archive, und das Programm, das sie verarbeitet, heißt schlicht rpm – RedHat Package Manager.

Das rpm-Programm lässt sich dabei sehr gut mit dem bereits vorgestellten dpkg von Debian vergleichen und erwartet auch ähnliche Optionen, die wir im Folgenden kurz durchgehen wollen, damit Sie einen Eindruck von diesem Programm gewinnen.

Pakete installieren und löschen

Heruntergeladene Pakete installiert man ganz einfach mit der -i-Option, und genau wie bei dpkg muss als Argument der volle Dateiname angegeben werden:

# rpm -i tkphone-1.0.2-2.i386.rpm

Listing 9.28    Pakete installieren mit rpm

Pakete löscht man äquivalent mit der -e (»erase«)-Option und dem Paketnamen.

alien

Pakete konvertieren

Oft steht man jedoch auch vor dem Problem, dass man ein bestimmtes Programm zwar im Internet gefunden hat, aber kein passendes Paket für die eigene Distribution vorfindet. Für diesen Fall gibt es das alien-Tool, das Pakete unterschiedlicher Distributionen ineinander konvertieren kann. Anzugeben ist dabei zum einen das heruntergeladene und zu konvertierende Paket sowie natürlich das Zielformat. Im Einsatz sieht das Ganze dann ungefähr so aus:

# alien --to-rpm tkphone_1.0.2-1_i386.deb 
tkphone-1.0.2-2.i386.rpm generated 
# ls tkphone* 
tkphone_1.0.2-1_i386.deb  tkphone-1.0.2-2.i386.rpm

Listing 9.29    Paketumwandlung mit alien

Das in diesem Beispiel von DEB zu RPM umgewandelte Paket könnte nun auf dem eigenen System installiert werden.

Da die Paketformate allerdings sehr unterschiedlich sind und natürlich auch die Distributionen trotz aller Ähnlichkeiten von der Dateistruktur teilweise noch recht unterschiedlich aufgebaut sind, wird dringend davon abgeraten, wichtige Systemsoftware durch alien-Pakete zu ersetzen – man würde wohl ziemlich sicher das System zerschießen.

Aber es gibt auch noch andere, etwas absonderliche Formen der Interaktion – zum Beispiel kann das rpm-Programm des RedHat-Paketsystems auch unter Debian als optionales Paket nachinstalliert werden. Damit könnte man dann theoretisch zwei Paketsysteme auf einem Rechner laufen haben, was aber nur bedingt sinnvoll ist.

$ apt-cache search rpm | grep "^rpm " 
rpm – Red Hat package manager 
$

Listing 9.30    Kurios: RedHat-Paketmanager unter Debian

Als Fazit kann man aus diesem Abschnitt mitnehmen, dass sich die unterschiedlichen Paketverwaltungssysteme bis auf wenige Unterschiede durchaus ähnlich sind. Schließlich kümmern sich die Systeme bei allen Unterschieden immer um dasselbe: Es soll Software installiert werden. Dabei können Abhängigkeiten und Konflikte auftreten, und manchmal sollen auch diverse Skripts zur Konfiguration vor, während oder nach der Installation des Pakets ausgeführt werden.

9.2.4 .tgz Packages unter Slackware 

Slackware-Linux und diverse auf Slackware basierende Distributionen (wie etwa Easys, Hardened Linux, Slamd64, SLAX oder Zenwalk) benutzen das Slackware-Paketformat, das ein einfaches .tar.gz-Archiv mit zusätzlichen Dateien darstellt.

Allerdings verwenden nicht alle dieser Distributionen die blanken Slackware Package Tools, sondern fügen teilweise noch zusätzliche Funktionalitäten hinzu, die Slackware von Haus aus nicht bietet. Zenwalk verwendet beispielsweise das Programm netpkg, das die Slackware-Packages um Abhängigkeiten erweitert. Es existieren noch weitere Tools, die dieses Paketformat erweitern. Dazu zählen unter anderem slackpkg und slapt-get.

Im Folgenden werden wir uns mit den Basisprogrammen zur Verwendung von Slackware-Paketen beschäftigen.

Paketnamen

Der Name einer Paketdatei setzt sich dabei generell aus dem Namen der Software, der Version, der Prozessorachitektur, für die das Paket übersetzt wurde, und einer Nummer zusammen, die angibt, um die wievielte Version des Packages es sich handelt.

Die einzelnen Werte werden dabei durch einen Bindestrich getrennt, und das Paket bekommt die Dateiendung .tgz.

Ein korrekter Paketname für den Linux-Kernel in der Version 2.6.20.1, der für die x86-Intel-Prozessoren (i386) übersetzt wurde und die erste Paketversion bezeichnet, würde also linux-2.6.20.1-i386-1.tgz heißen.

pkgtool

pkgtool

Es gibt verschiedene Methoden zur Installation und Deinstallation der Packages.

Die komfortabelste ist wohl das pkgtool.

Dieses kann Packages aus einem Verzeichnis, aber auch von Diskette installieren, und bietet eine grafische Oberfläche auf Konsolen-Ebene.

Abbildung 9.4    pkgtool

Möchten Sie beispielsweise das Package gnuplot von der Slackware-CD-ROM installieren, mounten Sie diese und starten im Verzeichnis slackware/xap der CD pkgtool. Wählen Sie anschließend den Menüpunkt »Current« aus, um die Packages dieses Verzeichnisses zu installieren. Beim entsprechenden Package sollte »yes« ausgewählt werden.

Abbildung 9.5    Package-Installation mit pkgtool

installpkg

Die Kommandovariante zur Package-Installation nennt sich installpkg.

Die Handhabung dieses Programms ist ebenfalls sehr simpel. Als Parameter genügt die tgz-Datei des Packages. Der Parameter -warn zeigt Ihnen an, welche Veränderungen vorgenommen würden, sofern ein Package installiert werden würde.

# installpkg gnuplot-4.0.0.-i486-1.tgz 
Installing package gnuplot-4.0.0-i486-1... 
PACKAGE DESCRIPTION: 
gnuplot: gnuplot (plotting utility) 
gnuplot: 
gnuplot: Gnuplot is a command-line driven interactive 
function plotting utility 
gnuplot: for UNIX, MSDOS, and VMS platforms.  The 
software is copyrighted but 
gnuplot: freely distributed (i.e., you don't have to 
pay for it).  It was 
gnuplot: originally intended as graphical program 
which would allow scientists 
gnuplot: and students to visualize mathematical 
functions and data.  Gnuplot 
gnuplot: supports many different types of terminals, 
plotters, and printers 
gnuplot: (including many color devices, and pseudo- 
devices like LaTeX) and is 
gnuplot: easily extensible to include new devices. 
gnuplot:

Listing 9.31    installpkg installiert gnuplot.

Deinstallation eines Packages

Zur Deinstallation eines Packages kann pkgtool hervorragend verwendet werden. Wählen Sie einfach den Menüpunkt »Remove – Remove packages that are currently installed« aus. Anschließend erscheint eine Liste mit installierten Packages, aus denen Sie nur das gewünschte zur Deinstallation auszuwählen brauchen.

Eine Kommandomöglichkeit zur Deinstallation ist removepkg.

Pakete löschen

Dieses Tool benötigt nur den Namen des Packages, und schon werden die Dateien des Packages deinstalliert.

Auch hier ist der -warn-Parameter von installpkg vorhanden.

# removepkg gnuplot-4.0.0-i486-1 
 
Removing package /var/log/packages/gnuplot-4.0.0-i48 
6-1... 
Removing files: 
  --> Deleting /usr/bin/gnuplot 
  --> Deleting /usr/doc/gnuplot-4.0.0/BUGS 
  --> Deleting /usr/doc/gnuplot-4.0.0/CodeStyle 
  --> Deleting /usr/doc/gnuplot-4.0.0/Copyright 
  --> Deleting /usr/doc/gnuplot-4.0.0/FAQ 
  --> Deleting /usr/doc/gnuplot-4.0.0/INSTALL 
  --> Deleting /usr/doc/gnuplot-4.0.0/NEWS 
  --> Deleting /usr/doc/gnuplot-4.0.0/PATCHLEVEL 
  --> Deleting /usr/doc/gnuplot-4.0.0/PGPKEYS 
  --> Deleting /usr/doc/gnuplot-4.0.0/PORTING 
…

Listing 9.32    removepkg deinstalliert gnuplot.

Updaten der Slackware-Packages

Das Kommando upgradepkg hat die gleiche Syntax wie die anderen beiden Verwandten removepkg und installpkg.

Das angegebene Package wird entfernt, und dessen neue Version wird installiert.

Im Folgenden soll die alte gaim-Version 0.78 durch eine neuere namens 1.0.2 ersetzt werden, die ein Sicherheitsloch schließt.

# upgradepkg gaim-1.0.2-i486-1.tgz 
 
+==================================================== 
| Upgrading gaim-0.78-i486-2 package using ./gaim-1.0 
.2-i486-1.tgz 
+==================================================== 
 
 
Pre-installing package gaim-1.0.2-i486-1... 
 
Removing package /var/log/packages/gaim-0.78-i486-2- 
upgraded-2005-02-04,14:32:46... 
--> Deleting /usr/doc/gaim-0.78/ABOUT-NLS 
--> Deleting /usr/doc/gaim-0.78/AUTHORS 
--> Deleting /usr/doc/gaim-0.78/COPYING 
--> Deleting /usr/doc/gaim-0.78/CREDITS 
--> Deleting /usr/doc/gaim-0.78/ChangeLog 
--> Deleting /usr/doc/gaim-0.78/FAQ 
--> Deleting /usr/doc/gaim-0.78/HACKING 
--> Deleting /usr/doc/gaim-0.78/NEWS 
--> Deleting /usr/doc/gaim-0.78/README 
--> Deleting /usr/include/gaim-remote/remote-socket.h 
--> Deleting /usr/include/gaim-remote/remote.h 
--> Deleting empty directory /usr/include/gaim-remote 
--> Deleting empty directory /usr/doc/gaim-0.78/ 
 
Installing package gaim-1.0.2-i486-1... 
PACKAGE DESCRIPTION: 
gaim: gaim 
gaim: 
gaim: Gaim allows you to talk to anyone using a... 
... 
... 
Executing install script for gaim-1.0.2-i486-1... 
 
Package gaim-0.78-i486-2 upgraded with new package 
./gaim-1.0.2-i486-1.tgz.

Listing 9.33    upgradepkg gaim

Paketinhalt entpacken

explodepkg

Der Paketinhalt lässt sich mit dem Programm explodepkg in das aktuelle Arbeitsverzeichnis entpacken. Dabei werden die Skripte, die im Paket enthalten sind, nicht ausgeführt. Alternativ kann man Slackware-Packages auch mit tar -xvzf Paket.tgz entpacken.

Pakete erstellen

makepkg

Slackware-Pakete können auch relativ einfach selbst erstellt werden, was mit dem Programm makepkg erledigt wird. Der folgende Aufruf würde ein Paket der Software »MeinTool« erstellen. -l y bewirkt dabei, dass auch symbolische Links in das Package aufgenommen werden, und -c n bewirkt, dass die Zugriffsrechte von Verzeichnissen nicht automatisch auf »755« und den Eigentümer root:root gesetzt werden.

$ makepkg -l y -c n MeinTool-1.0-i386-1.tgz

slack-desc und doinst.sh

makepkg verwendet für den Inhalt des Packages übrigens den Inhalt des aktuellen Arbeitsverzeichnisses. In diesem sollte sich ein Verzeichnis namens install/ befinden. In diesem Verzeichnis sollte eine Datei namens slack-desc stecken, die eine kurze Beschreibung des Paketinhalts enthält. Bei Bedarf kann noch die Datei doinst.sh im install-Verzeichnis abgelegt werden. Dabei handelt es sich um ein Shellskript, das bei der Installation automatisch ausgeführt wird.

9.2.5 Das Gentoo Portage System 

Das Paketsystem von Gentoo ist dem BSD-Ports-System – auf das wir anschließend noch zu sprechen kommen – sehr ähnlich. Unter Gentoo Linux werden Pakete aus dem Quellcode kompiliert, was eine bessere Anpassung der Pakete an die Prozessorarchitektur des Rechners sowie eine Verbesserung der Performance mit sich bringen kann. Der Nachteil besteht darin, dass es viele Stunden (auf langsamen Rechnern gar Tage!) dauert, die Programme eines Systems vollständig zu übersetzen. Auch bei einem Paket-Update muss erneut kompiliert werden, was bei großen Programmen wiederum Stunden dauern kann.

emerge

Gesteuert wird das Gentoo Portage System über das Programm emerge, das sich darum kümmert, die einzelnen Ports zu übersetzen, zu suchen, zu erneuern und zu installieren. Dabei werden automatisch auch Abhängigkeiten aufgelöst.

(De-)Installation

Möchte man ein Programm installieren, so ruft man emerge mit dessen Namen, also etwa mit emerge vim, auf. Mit emerge -C vim würde man das gleiche Programm hingegen wieder deinstallieren.

Updates

Das Paketsystem (und zwar das ganze) kann durch einen Aufruf von emerge -uD world auf den neuesten Stand gebracht werden.

Ports suchen

Auch die Suche von Software kann mit emerge erledigt werden. Dabei sucht man entweder nur nach einem Paketnamen (-s Suchbegriff) oder durchsucht auch die die Paketbeschreibung (-S Suchbegriff).

Portage updaten

Das Portage-Verzeichnis, das eine Liste der verfügbaren Ports enthält, lässt sich ebenfalls ganz einfach durch emerge sync aktualisieren.

9.2.6 BSD-Ports 

Nun kommen wir zu den bereits oben erwähnten Ports. Ports werden primär unter BSD-Systemen verwendet und sind nicht mit den Portierungs-Ports zu verwechseln. Ein Portierungs-Port, etwa i386, ist die Portierung eines Systems auf eine bestimmte Prozessorarchitektur, ein Software-Port hingegen enthält Anweisungen, um eine Software aus dem Quellcode heraus zu übersetzen und eventuell um diese Quellen zunächst automatisch herunterzuladen.

Das Prinzip ist immer sehr ähnlich: Man lädt ein Archiv, das die Dateien der aktuellen Ports enthält, von einem Server, entpackt dieses Archiv, geht systematisch in ein entsprechendes Unterverzeichnis, startet einen automatischen Vorgang zur Installation eines Ports und kann diesen anschließend verwenden.

distfiles

Dabei werden die Quelldateien meist direkt von den Servern der Entwickler heruntergeladen und im sogenannten distfiles-Unterverzeichnis gespeichert. Dieses Verzeichnis enthält alle heruntergeladenen Archive und sollte nicht gelöscht werden. Löschen Sie dieses Verzeichnis auch nicht, wenn Sie eine neuere Version der Ports herunterladen, denn sonst müssen die Dateien, die schon vorhanden waren und erneut benötigt werden, nochmals heruntergeladen werden.

Natürlich muss man unter BSD nicht zwangsläufig auf Ports zurückgreifen, man kann sich bei jedem populären Derivat auch die fertig übersetzten Binärpakete herunterladen und installieren lassen. Dies funktioniert genauso wie unter Debian oder Slackware, nur dass die Tools anders heißen, etwa pkg_add.

NetBSD Package Collection

Um die NetBSD Package Collection zu installieren, benötigt man zunächst einmal deren aktuelle Version. Diese findet man auf dem FTP-Server von NetBSD, wobei die Datei pkgsrc.tar.gz geladen werden muss. <http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/tar_files/>

Diese Datei entpackt man üblicherweise in das Verzeichnis /usr, in dessen Unterverzeichnis pkgsrc anschließend der Ports-Tree zu finden ist.

# wget ftp://..../pkgsrc.tar.gz 
# cd /usr 
# tar -xzf pkgsrc.tar.gz 
# cd pkgsrc 
# ls 
...

Listing 9.34    Laden und entpacken

Im pkgsrc-Verzeichnis finden Sie verschiedenste Unterverzeichnisse. Diese Unterverzeichnisse unterteilen die Ports in verschiedene Kategorien und stellen somit eine größere Übersicht her, als wenn alle Ports in einem Verzeichnis liegen würden. Einen Mail-Client wird man schließlich nicht im sysutils-Verzeichnis suchen.

Hat man sich für einen Port entschieden, wechselt man in das jeweilige Verzeichnis des Ports und führt make aus. Dadurch werden die benötigten Quelldateien heruntergeladen und der Port (falls nötig) kompiliert. Außerdem werden eventuell benötigte Abhängigkeiten von Ports automatisch erkannt und heruntergeladen. Sollten diese Abhängigkeiten wiederum Abhängigkeiten aufweisen, werden diese ebenfalls heruntergeladen und so weiter.

Würden Sie zum Beispiel KDE installieren wollen, benötigt Ihr System zunächst einmal diverse Bibliotheken und Programme, die ihrerseits wiederum andere Bibliotheken benötigen. Das Ports-System kümmert sich um all diese Abhängigkeiten – Sie müssen nur lange genug warten, bis alles geladen, entpackt und kompiliert worden ist. <Falls Sie einen langsamen Rechner und eventuell eine Modem-Anbindung haben, sollten Sie nicht mit KDE starten, da dieser Übersetzungsvorgang dann durchaus mehrere Tage dauern könnte.>

Nach dem Übersetzungsvorgang muss das jeweilige Paket noch vorkonfiguriert und installiert werden. Dies wird mit einem Aufruf von make install bewerkstelligt. Anschließend kann man die entpackten Quelldateien sowie die kompilierten Objektdateien wieder löschen, um Plattenplatz freizugeben. Mit make clean wird das für den jeweiligen Port übernommen. make clean-depends »räumt« auch noch die gesamten Abhängigkeiten auf.

Die heruntergeladenen Archivdateien finden Sie im Verzeichnis /usr/pkg/distfiles.

OpenBSD Ports-Tree

Den OpenBSD Ports-Tree bezieht man ebenfalls vom jeweiligen FTP-Server des Projekts als Archivdatei (ports.tar.gz). <ftp.openbsd.org/pub/OpenBSD/>

Nachdem man diese Datei ebenfalls in /usr entpackt hat, wechselt man in das Verzeichnis ports. Dort findet man eine Verzeichnishierachie vor, die der der NetBSD Package Collection sehr ähnlich ist. Der Vorgang zur Installation von Software wird auf dieselbe Weise bewerkstelligt wie unter NetBSD.

Installieren wir beispielsweise mal das KDE3-Basis-System:

# cd /usr/ports 
# cd x11/kde/base3 
# make 
... 
# make install 
... 
# make clean 
===> Cleaning for kdebase-3.4.1 
# make clean-depends 
===>  Cleaning for bzip2-1.0.3 
===>  Cleaning for aspell-0.50.5p1 
===>  Cleaning for docbook-dsssl-1.72 
===>  Cleaning for help2man-1.29 
===>  Cleaning for autoconf-2.59 
===>  Cleaning for autoconf-2.57 
===>  Cleaning for autoconf-2.54 
===>  Cleaning for metaauto-0.5 
...

Listing 9.35    Den Port kde/base3 installieren

Sie können diesen Vorgang übrigens auch mit einem einzelnen Aufruf von make verkürzen:

# alias create_port="make && make install clean \ 
clean-depends"

Listing 9.36    Alias für make

Die anschließend heruntergeladenen Archivdateien finden Sie im Verzeichnis /usr/ports/distfiles.

FreeBSD Ports Collection

Um die Ports Collection unter FreeBSD zu beziehen, verwendet man entweder /stand/sysinstall (unter Configure • { Distributions • {} Ports}) oder CVS. Die Installation der Ports erfolgt ebenfalls via make und make install.

Wichtige Dateien

Doch wie ist so ein Port eigentlich aufgebaut? Je nach Derivat ist dies etwas verschieden. Allerdings lässt sich zumindest grob erläutern, wie es im Allgemeinen der Fall ist. Im jeweiligen Port-Verzeichnis finden sich, wenn man vom Beispiel OpenBSD ausgeht, folgende wichtige Dateien:

• CVS

• Das CVS-Verzeichnis. Es wird benötigt, um die aktuelle Version eines Ports herunterzuladen.

• Makefile

• Die Makefile enthält wichtige Informationen zum Port: eine kurze Beschreibung, die Abhängigkeiten und die Versionsnummer.

• distinfo

• In dieser Datei sind die Prüfsummen der jeweiligen distfile enthalten.

• patches

• Dieses Verzeichnis enthält die Patches, die benötigt werden, um die Software zu kompilieren.

• pkg/DESCR

• Diese Datei enthält ausführliche Informationen zum Port.

• pkg/PLIST

• Diese Datei enthält Dateien, die zu dieser Software gehören und installiert werden.

Unter anderen Systemen haben diese Dateien sehr ähnliche Namen, so heißt pkg-descr unter FreeBSD beispielsweise DESCR.

# cd /usr/ports/mail/sylpheed 
# more Makefile 
COMMENT=        "mail/news client in gtk+" 
 
VERSION=        1.0.4 
DISTNAME=       sylpheed-${VERSION} 
CATEGORIES=     mail news x11 
HOMEPAGE=       http://sylpheed.good-day.net 
MAINTAINER=     Damien Couderc <couderc@openbsd.org> 
 
LIB_DEPENDS=    gdk_pixbuf.2::graphics/gdk-pixbuf 
 
# GPL 
PERMIT_PACKAGE_CDROM=   Yes 
PERMIT_PACKAGE_FTP=     Yes 
PERMIT_DISTFILES_CDROM= Yes 
PERMIT_DISTFILES_FTP=   Yes 
WANTLIB=                X11 Xext Xi c crypto gdk \ 
                        glib gmodule gtk iconv intl \ 
                        jpeg m png pthread ssl tiff z 
 
MASTER_SITES=   ${HOMEPAGE}/sylpheed/v1.0/ 
... 
# more pkg/DESCR 
Sylpheed is an e-mail client (and news reader) based 
on GTK+, running on the X Window System, and aiming 
for: 
 
     Quick response 
     Graceful, and sophisticated interface 
     Easy configuration, intuitive operation 
     Abundant features 
 
FLAVORS: 
        * compface: support X-Face header 
        * gpgme: compile with gnupg made easy support

Listing 9.37    Wichtige Informationen am Beispiel von sylpheed

Port-Management

Update

Das Port-Management gestaltet sich recht simpel.

Ein Update des Ports-Tree wird durchgeführt, indem entweder eine neue Archivdatei der Ports vom jeweiligen Server geladen wird oder indem ein CVS-Update durchgeführt wird. <I Kapitel 21, »Softwareentwicklung«, erfahren Sie Genaueres zur Nutzung des CVS.> Vergessen Sie jedoch nie, ein Backup der distfiles durchzuführen!

Packages löschen

Ports und Packages werden meist mit einem Tool wie pkg_delete gelöscht.

Informationen

Informationen zu installierten Ports und Packages erhält man mittels pkg_info.

Packages installieren

Kompilierte Ports, also Packages, kann man in der Regel mit pkg_add installieren und sogar direkt herunterladen lassen.

Weitere Möglichkeiten

Zudem gibt es noch Tools wie pkg_create, um selbst Packages zu erstellen. Weitere Tools, etwa NetBSDs pkg_admin oder pkglint, sollen an dieser Stelle nicht angesprochen werden. Weiterführende Informationen finden Sie in der jeweiligen Online-Dokumentation und in den Manpages.

9.2.7 Softwareinstallation ohne Pakete 

Irgendwann kommt ein Punkt, an dem man im Internet ein nettes Programm findet, für das aber noch niemand ein passendes Paket erstellt hat. Dann bleibt einem oft nichts anderes übrig, als das Programm »von Hand« zu installieren. Da Linux selbst ein Produkt der Open-Source-Gemeinde ist, sind auch sehr viele Programme frei. Das bedeutet, dass Sie alle Quelltexte der entsprechenden Programme bekommen können, und oft werden Ihnen auch nur diese vorgesetzt. Es ist also notwendig, mit solchen Situationen umgehen zu können.

Das Standardvorgehen

Zuallererst brauchen Sie die richtige Software, um solche Quellcodes zu übersetzen. In den Installationsroutinen verschiedener Distributionen kann man dazu meist Punkte wie »Development« oder Ähnliches auswählen. Als Nächstes muss man die oft gepackt gelieferten Sourcen irgendwohin entpacken:

$ tar -xzf quellen.tar.gz

Listing 9.38    Entpacken eines Archivs

Im Normalfall hat man jetzt ein neues Verzeichnis, in das man mit dem cd-Kommando wechseln kann. Dann kann man sich in aller Ruhe eventuell vorhandene READMEs in den INSTALL-Dateien durchlesen. Fast immer reduziert sich die Installation jedoch auf die folgenden Befehle:

$ cd quellen-x.y 
$ ./configure 
$ make 
... 
$ su 
Password: 
# make install 
... 
# exit 
$

Listing 9.39    Kompilieren von Quellcode

Dabei wird zuerst das Paket mittels »./configure« konfiguriert, und dann mit »make« übersetzt.

Schließlich kopiert man als root mit »make install« die fertigen Programme dann noch an die richtige Stelle des Dateisystems.

Standardmäßig werden selbst erstellte Programme nicht in die »normalen« Verzeichnisse wie /usr/bin usw.

kopiert, sondern in eine Extrahierarchie unter /usr/local. Die fertigen Binaries würden sich dann beispielsweise unter /usr/local/bin und die Manpages in /usr/local/man befinden. Das hat den Vorteil, dass das Deinstallieren der Programme von Hand recht einfach ist. Zudem trennt man so Distributionsspezifisches sauber von selbst Hinzugefügtem.

Leider ist jede Software anders, und je nachdem, wie der oder die Autoren das Paket entworfen haben, kann der Installationsvorgang auch einmal anders aussehen. Allerdings sind das Vorgehen sowie alle Voraussetzungen meistens im Detail beschrieben, sodass das Kompilieren auch dann keine so große Hürde mehr darstellt.

Das Vorgehen bei Problemen

Allerdings klappt natürlich nicht immer alles so reibungslos. Im Folgenden wollen wir kurz die wichtigsten Fehler und deren Ursachen behandeln und abklären.

configure schlägt fehl

Mit configure konfigurieren wir das Paket. Das heißt, es wird zum Beispiel geprüft, welche Bibliotheken

(»libs«) in welchen Versionen vorhanden sind und ob bestimmte Voraussetzungen erfüllt sind. Eigentlich macht also configure nichts anderes, als die Abhängigkeiten, wie sie bei Paketen von den Distributoren per Hand eingestellt werden, vor dem Kompilieren zu überprüfen. Treten hier Fehlermeldungen auf, so sind sie meist selbsterklärend.

Oft reicht es dann aus, wenn man zum Beispiel fehlende Bibliotheken einfach nachinstalliert, also sich noch einmal die Installations-CDs heranholt bzw. einfach mal ein apt-get install lib_die_fehlt probiert. Unter Debian gibt es Include-Dateien. Diese Dateien sind eine Art Inhaltsverzeichnis für Softwarebibliotheken. Dass configure sie nicht findet, hat oft zwei Gründe:

• Falsches Verzeichnis

• Include-Dateien werden natürlich standardmäßig in bestimmten Verzeichnissen vermutet. Manchmal können sich also durch Versionsnummern oder aufgrund der Tatsache, dass es sich bei Ihrem System um eine andere Distribution als bei den Programmierern handelt und die Verzeichnisse etwas anders strukturiert sind, die Include-Dateien woanders befinden. Setzen Sie doch einfach einen Link, oder kopieren Sie alles entsprechend an die richtige Stelle. Oder vielleicht muss auch nur eine Shell-Variable gesetzt werden? Manchmal hilft bei solchen Problemen, die zugegeben eher selten auftreten, auch die README oder eine FAQ weiter.

• Falsche Bibliotheksversion

• Manche Distributionen wie beispielsweise Debian unterscheiden in ihren Paketen teilweise zwischen Bibliotheken für normale Systeme und Bibliotheken zum Programmieren – das hat den Vorteil, dass eine normale Installation so erheblich kleiner wird, da Include-Dateien wirklich nur zum Übersetzen gebraucht werden.

• Allerdings kann man manchmal schon verzweifeln, da man die entsprechende Bibliothek ja wirklich installiert hat, aber trotzdem nichts funktioniert.

• In so einem Fall versuchen Sie einfach mal ein apt-get install (lib)-dev für die Development-Version.

• Manchmal benötigt ein Programm vielleicht eine ältere Bibliothek, die nicht mehr auf dem System installiert ist. In so einem Fall ist allerdings Fingerspitzengefühl gefragt, damit es nicht zu Problemen mit veränderten Abhängigkeiten kommt.

Wenn make abbricht

Tritt beim Kompilieren ein Fehler auf, dann ist entweder eine Bibliothek nicht vorhanden oder es liegt ein Programmierfehler vor – Letzteres ist allerdings sehr selten, und normalerweise kann man auch nichts machen. In so einem Fall hilft dann einfach nur das Warten auf eine neue Version oder eine Mail an die Entwickler.

make install funktioniert nicht

Wenn make install einen Fehler liefert, liegt das meist an fehlenden Rechten und seltener an unfähigen Programmierern. Falls Sie wirklich root sind, können Sie ja versuchen, aus den Fehlermeldungen schlau zu werden – einen allgemeinen Lösungsvorschlag kann man hier leider nicht geben.

Ihr Kommentar