Galileo Computing :: Linux - 14 Grundlegende Verwaltungsaufgaben

14.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 dem Thema 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 umfasst die ausführbare Programmdatei (Binärdatei oder Skript), Manpages, zusätzliche Dokumentation (die zum Beispiel im HTML-Format oder als TeX-Datei vorliegt), vorgefertigte Konfigurationsdateien und manchmal auch Skripte, um die Software zu starten und zu beenden. [Fn. Solche Startskripte finden sich in der Regel im Verzeichnis /etc/init.d oder /etc/rc.d und werden für Dienste verwendet, die permanent laufen und daher beim Systemstart automatisch gestartet werden sollen.]

Bei Ports wird die Software hingegen erst aus dem Quellcode kompiliert. Bei einem Port werden die Binärdateien also nicht mitgeliefert, sondern frisch erzeugt.

Ein Paket oder Port muss aber nicht immer eine Software – und damit ein Skript oder eine Binärdatei – enthalten. Typische Beispiele hierfür sind etwa Dokumentationspakete, die nur Dokumentationsdateien enthalten. Unter Slackware gibt es bspw. auch 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) umfasst.

Zudem kann eine Software auch aus mehreren Paketen bestehen. Der Apache-Webserver ist bei einigen Distributionen beispielsweise in die eigentliche Webserver-Software und die zugehörige Administrationssoftware aufgeteilt, so dass man zwei oder noch mehr Pakete installieren muss, um »alles, was dazugehö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 der Distributor selbst.

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

Die meisten Updates werden über Internetverbindungen durchgeführt. Bandbreite kostet sowohl den Distributor als auch den Benutzer Zeit und Geld. Komprimierte Pakete können die zu übertragende Datenmenge sehr verkleinern.
Einige Distributionen sind auch auf CDs und DVDs erhältlich, enthalten aber im Extremfall über 20.000 einzelne Pakete, die bereits im komprimierten Format auf fünf, sechs oder noch mehr Medien verteilt werden müssen. Je besser dabei die Komprimierung ist, desto weniger CDs/DVDs werden benötigt, um eine Distribution zu vertreiben, was nicht nur Geld für Rohlinge spart, sondern Ihnen auch häufiges Wechseln von Datenträgern während der Installation erspart. [Fn. Frühere Slackware-Versionen waren übrigens auf ganze 80 Disketten verteilt!]

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

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

Wie heißt das Paket und in welcher Version liegt es vor? Dazu kommen weitere Informationen zum Paket, beispielsweise Kurzbeschreibungen und Schlagwörter.
Welche Arbeiten (Skripts) sind auszuführen, wenn das Paket installiert, aktualisiert oder gelöscht werden soll?
Welche weiteren Softwarepakete (Abhängigkeiten) werden benötigt, damit das Paket läuft?

Unterschiedliche Standards

Je nachdem, wie die Pakete und die Paketverwaltung organisiert sind, spricht man von unterschiedlichen Paketsystemen. Die bekanntesten Softwareverwaltungsformate aus der Linux-Welt sind auch tatsächlich paketbasierte, wie etwa das deb-Format von Debian oder RPM von RedHat beziehungsweise SUSE. Die zugehörigen Pakete sind eigentlich nichts weiter als Archive [Fn. 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 Skripte gibt, die jeweils beim Installieren, Updaten oder Löschen ausgeführt werden.

Pakete werden dann schließlich entweder im Internet oder auch auf CD zu sogenannten Repositories – also zu Verzeichnissen [Fn. 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 Umgang mit Metadaten haben die BSD-Derivate 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 (eine der wenigen Linux-Distributionen mit einem Ports-ähnlichen System) oder Tcl bei MacPorts (einem Ports-System für Mac OS X) verwendet werden.

14.2.2 APT – Advanced Packaging Tool

Stellvertretend für RPM- und DEB-basierte Systeme soll hier die Paketverwaltung mit 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 jedoch allesamt ohne große Änderungen auch auf RPM-basierte Systeme übertragen.

Die Datei sources.list

Welches Repository?

In der Datei /etc/apt/sources.list kann man zuerst einmal die Repositories festlegen. Diese 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 über HTTP oder FTP zugegriffen werden soll oder wie viele unterschiedliche Repositories definiert wurden. Betrachten wir also eine mögliche sources.list:

Listing 14.16 Eine beispielhafte 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
deb ftp://ftp.nerim.net/debian-marillat/ unstable main

[zB]In diesem Beispiel wurden zwei Repositories definiert: eines auf dem Server ftp.de.debian.org, von dem Binär- und Quellpakete (deb oder deb-src) geladen werden können, und zum anderen eines auf dem Rechner ftp.nerim.net, von dem offensichtlich nur Binärpakete geladen werden sollen. Die weiteren Argumente bezeichnen 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 davon enthält nun eine Datei Packages, die die Informationen sowie den Speicherort der 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 bzw. safe-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 bzw. full-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.

Pakete installieren!

install <Paket>
Mit dieser Option kann man ein neues Paket installieren. Die Abhängigkeiten werden dabei automatisch bestimmt und nach einer kurzen Nachfrage auf Wunsch mitinstalliert.
remove (--purge) <Paket> ... <Paket>+
Das Gegenstück zu install ist remove. Möchte man ein oder mehrere Pakete deinstallieren, 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 Pakete löschen und gleichzeitig andere installieren, so reicht es, beim remove ein + an die zu installierenden Pakete anzuhängen. So verhindert man das Problem, dass man eines von zwei sich gegenseitig ausschließenden Paketen installiert hat, 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 etwas kommt durchaus vor. Sehen wir uns nun eine beispielhafte Deinstallation an:

Listing 14.17 Das Paket xmame-x deinstallieren

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

Hierbei 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, wenn diese Abhängigkeiten nicht mehr bestehen – wie hier im Beispiel das Paket xmame-common, das nach der Deinstallation von xmame-x nicht mehr benötigt und daher auch gelöscht wird.

source <Paket>
Diese Option ruft ein Quellpaket von einem der mit deb-src bezeichneten Repositories ab. Das Paket wird heruntergeladen und im aktuellen Verzeichnis als .tar.gz-Archiv gespeichert. Zu bemerken bleibt noch, dass sich normale Repositories (deb) von Quellen-Repositories (deb-src) unterscheiden und so ein Quellpaket nicht immer in derselben Version wie ein Binärpaket verfügbar sein muss. Auch ist es wichtig zu wissen, dass die Installation eines Quellpakets nicht weiter registriert wird.

Ein solches entpacktes Quellpaket kann man unter Debian mit dpkg-build- package übersetzen. Damit das Programm weiß, was es tun soll, liest es die in jedem Debian-Quellpaket vorhandene Datei debian/rules aus. Möchte man also die Installationsoptionen verändern – was meistens der Grund für das Heranziehen eines Quellpaketes ist --, so muss man diese Datei entsprechend ändern und anschließend dpkg-buildpackage aufrufen, das eine .deb-Datei mit der eben übersetzten Software enthält. Dieses Paket kann nunmehr mittels dpkg -i <Paket-Datei> 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 Quellen nun übersetzen will. Mit der Option build-dep werden nämlich alle für das übersetzen des Quellpaketes <Paket> benötigten Pakete installiert.

Cache leeren

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

Sie können also mit apt-get fast die gesamte Paketverwaltung auf einfache Weise von der Kommandozeile aus organisieren. Aber natürlich können Sie auch 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. Um also nach Paketen zum Programm xchat zu suchen, nutzen Sie folgenden Befehl:

Listing 14.18 Pakete suchen mit apt-cache

$ 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

Die Details eines bestimmten Pakets können Sie sich schließlich mit dem Parameter show anzeigen lassen:

Listing 14.19 Paketdetails für »exim«

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

Offline verfügbar

Beachten Sie dabei, dass alle diese Informationen aus der Packages-Datei des Repositories stammen. Das Paket muss also weder installiert sein noch heruntergeladen werden, um eine solche Suche durchführen zu können. 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 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 als Paketnamen an. Falls notwendig, wird hinter dem Paketnamen angegeben, welche Version genau (=) oder mindestens (>=) vorausgesetzt wird.
Suggests
Diese Pakete werden vom betrachteten Paket vorgeschlagen. Im Regelfall werden sie 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 Worte: Man kann immer nur einen MTA installieren.
Filename
Unter diesem Dateinamen ist das Paket auf dem Repository zu finden.
MD5sum
Hier steht die Prüfsumme des Pakets. Anhand ihrer können eventuelle Veränderungen festgestellt werden.
Description
Der letzte Punkt enthält schließlich eine kurze Beschreibung des Pakets. Hier erfahren wir, dass exim 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 (open-)SUSE und Redhat (beziehungsweise Fedora) verstanden: Dieses 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 übersichtliches Frontend für die Konsole bereit, das viele Aufgaben erleichtert und alles »unter einem Dach« zusammenfasst.

Abbildung 14.1 Das Repository updaten

Text-Interface

Die Funktionalität entspricht dabei der von apt-get, mit dem einzigen Unterschied, dass Aktionen nicht über Kommandozeilenparameter, sondern über Tastenkürzel ausgeführt werden. Eine Liste aller Kü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, woraufhin aptitude mit dem Herunterladen der aktuellen Repository-Daten beginnt.

Ready ...

Daraufhin kann man im aptitude-Startbildschirm einen zusätzlichen Eintrag mit einer Liste aller aktualisierbaren Pakete sehen. In einer solchen Sektion navigiert man 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 herausspringen kann. 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 [Fn. 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 von U zum Upgraden auswählen beziehungsweise sogar in den Optionen festlegen, dass dies automatisch geschehen soll.

Abbildung 14.2 Der aptitude-Startbildschirm

Als Ergebnis sehen Sie schließlich in der Statusleiste eine Zusammenfassung aller Platzangaben. Sie können dort ablesen, wie sich der Plattenplatz verändern wird und wie viel dabei heruntergeladen werden muss (siehe Abbildung 14.2).

... Go!

Alle markierten Aktionen führen Sie schließlich über die Taste G (für go) aus. Infolgedessen sehen Sie nun noch einmal eine Liste aller vorgemerkten Aktionen. Diese bestätigen Sie durch nochmaliges Drücken von G.

Sodann beginnt der Download, gefolgt von der Installation aller heruntergeladenen Pakete. Eventuell werden Sie dabei, wie von apt-get gewohnt, zu manchen Konfigurationsdetails gefragt (siehe Abbildung 14.3).

Abbildung 14.3 Durchzuführende Aktionen

Bei dieser Auflistung ist, wie in der Paketliste auch, vor allem der Zustand interessant, der durch das vor jedem Paketnamen stehende Buchstabentripel angegeben wird. Der erste Buchstabe bezeichnet dabei den aktuellen Status: i steht für installierte, p für noch nicht installierte 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 bezeichnet nun besondere Eigenschaften von Paketen: Ein großes A gibt zum Beispiel an, dass ein Paket automatisch installiert wurde. Sobald es nicht mehr wegen irgendwelcher Abhängigkeiten benötigt wird, wird es automatisch deinstalliert. Der Administrator kann ein Paket auch im Nachhinein mit M als automatisch installiert markieren beziehungsweise diese Markierung wieder aufheben.

Pakete zurückhalten

Sie können auch Pakete mittels = von einem automatischen Update ausschließen. Sie werden dann mit einem h für hold markiert.

Abschließend sei hier noch die Syntax zum Suchen nach bestimmten Paketen erläutert: Wie von anderen Programmen wie less gewohnt, erreichen Sie eine Suchmaske durch Eingabe eines Slashs (/). Dort können Sie den Suchausdruck angeben und nach einer Bestätigung schließlich danach suchen lassen. In Suchausdrücken sind zwei besondere Zeichen erlaubt: »^« bezeichnet den Anfang des Paketnamens, und »$« entsprechend das Ende. So sucht man durch Eingabe von »test« nach allen Paketen mit dem Namensbestandteil »test« im Namen, während die Eingabe von »^test$« nur das Paket mit dem genauen Namen »test« findet.

Distributionsspezifische Tools

Hat man aptitude einmal verstanden, so wird man auch die Funktionsweise von anderen, vielleicht distributionsspezifischen Programmen zur Paketverwaltung problemlos 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.

14.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 dann nicht möglich, wenn das betreffende Paket nicht im Repository vorhanden ist, weil man z. B. die Paketdatei selbst per Hand von einer ominösen Seite heruntergeladen hat.

Zwei Programme, die solche Probleme 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, aber auch Ubuntu, und den Red-Hat-ähnlichen Distributionen wie Fedora oder SUSE mit dem RPM-System unterscheiden.

dpkg

Beginnen wir mit dem Programm dpkg. 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, ruft dpkg mit dem Parameter -i, gefolgt vom entsprechenden Dateinamen, auf:

Listing 14.20 Ein heruntergeladenes DEB-Paket installieren

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

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:

Listing 14.21 Alle installierten vim-Pakete anzeigen

$ 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

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:

Listing 14.22 Der Inhalt des Pakets »tuxracer«

$ 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

Oft möchte man nämlich wissen, was man eigentlich gerade installiert hat und wo entsprechende Dateien zu finden sind. Vor allem 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, so dass die entsprechenden Binärdateien nicht wie vielleicht erwartet im PATH zu finden sind.

Das »letzte Geheimnis« ist nun die bereits angesprochene Installation eines Quellpakets nach einer Übersetzung der mit apt-get source geladenen Quellen. Um zum Beispiel das Paket bash aus dem Quellcode zu installieren, muss man das Paket per apt-get laden:

Listing 14.23 Die bash-Sourcen installieren

$ 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
$

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:

Listing 14.24 Die build-Dependencies installieren

# 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) ...

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

Listing 14.25 Das Paket als root bauen

$ 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'.
#

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

Listing 14.26 Das Resultat 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
...

rpm

Die Pakete des Red-Hat-Paketsystems haben die Endung .rpm und ähnlich komplizierte Namen wie die des Debian-Paketsystems. Im Prinzip sind aber auch sie nur gepackte Archive, und das Programm, das sie verarbeitet, heißt schlicht rpm – Red Hat 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 ihm gewinnen können.

Pakete installieren und löschen

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

Listing 14.27 Pakete installieren mit rpm

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

Pakete löscht man entsprechend mit der Option -e (erase) und dem Paketnamen.

alien

Pakete konvertieren

Oft steht man jedoch auch vor dem Problem, dass man zwar ein bestimmtes Programm im Internet gefunden hat, aber kein passendes Paket für die eigene Distribution vorfindet. Für diesen Fall gibt es das Tool alien, 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:

Listing 14.28 Paketumwandlung mit alien

# 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

Das in diesem Beispiel von DEB in RPM umgewandelte Paket könnte nun auf dem eigenen System installiert werden. Da die Paketformate allerdings sehr unterschiedlich sind und auch die Distributionen trotz aller Ähnlichkeiten von der Verzeichnishierarchie her 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: So können Sie das rpm-Programm des RedHat-Paketsystems auch unter Debian als optionales Paket nachinstallieren. Damit können Sie dann theoretisch zwei Paketsysteme auf einem Rechner einsetzen, was aber nur bedingt sinnvoll ist.

Listing 14.29 Kurios: RedHat-Paketmanager unter Debian

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

Wie Sie gesehen haben, sind sich die unterschiedlichen Paketverwaltungssysteme bis auf wenige Unterschiede durchaus ähnlich. Schließlich kümmern sie sich bei allen Abweichungen im Detail immer um dasselbe: Es soll Software installiert werden. Dabei können Abhängigkeiten und Konflikte auftreten, und manchmal sollen auch diverse Skripte zur Konfiguration vor, während oder nach der Installation des Pakets ausgeführt werden.

14.2.4 Das Slackware-Paketsystem

Slackware-Linux und diverse auf Slackware basierende Distributionen (wie etwa Easys, 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ät 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 slapt-get und slackpkg. Im Folgenden werden wir uns mit den Basisprogrammen zur Verwendung von Slackware-Paketen beschäftigen.

[»]Seit Slackware 13.0 werden auch weitere Kompressionsformate, nämlich .tbz, .tlz und .txz, vom Paketsystem unterstützt.

Paketnamen

Der Name einer Paketdatei setzt sich dabei generell aus dem Namen der Software, ihrer Versionsnummer, der Prozessorarchitektur, 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 lauten: linux-2.6.20.1-i386-1.tgz.

pkgtool

Es gibt verschiedene Methoden zur Installation und Deinstallation der Packages. Die komfortabelste ist wohl das pkgtool. Es kann Packages aus einem Verzeichnis, aber auch von Datenträgern installieren und bietet eine grafische Oberfläche auf Konsolenebene.

Abbildung 14.4 pkgtool

Abbildung 14.5 Package-Installation mit 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 das Programm 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.

installpkg

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

Listing 14.30 Das Programm installpkg installiert gnuplot.

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

Deinstallation eines Packages

Auch 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 der Sie nur das gewünschte zur Deinstallation auszuwählen brauchen.

Eine kommandozeilenbasierte Möglichkeit zur Deinstallation ist removepkg. Dieses Tool benötigt nur den Namen des Packages und schon werden dessen Dateien deinstalliert. Auch hier ist der -warn-Parameter von installpkg vorhanden.

Listing 14.31 removepkg deinstalliert gnuplot.

# removepkg gnuplot-4.4.3-i486-1

Removing package /var/log/packages/gnuplot-4.4.3-i486-1...
Removing files:
  --> Deleting /usr/bin/gnuplot
  --> Deleting /usr/doc/gnuplot-4.4.3/BUGS
  --> Deleting /usr/doc/gnuplot-4.4.3/ChangeLog
  --> Deleting /usr/doc/gnuplot-4.4.3/CodeStyle
  --> Deleting /usr/doc/gnuplot-4.4.3/Copyright
  --> Deleting /usr/doc/gnuplot-4.4.3/INSTALL
  --> Deleting /usr/doc/gnuplot-4.4.3/NEWS
  --> Deleting /usr/doc/gnuplot-4.4.3/PATCHLEVEL
  --> Deleting /usr/doc/gnuplot-4.4.3/PGPKEYS
  --> Deleting /usr/doc/gnuplot-4.4.3/PORTING
  --> Deleting /usr/doc/gnuplot-4.4.3/README
...

Updaten der Slackware-Packages

Das Kommando upgradepkg hat die gleiche Syntax wie seine beiden Verwandten removepkg und installpkg. Das angegebene Package wird entfernt, und eine neue Version davon wird installiert.

Im Folgenden soll die alte pidgin-Version 2.7.11 durch eine neuere namens 2.9.0 ersetzt werden, die eine Sicherheitslücke schließt.

Listing 14.32 upgradepkg pidgin

# upgradepkg pidgin-2.9.0-i486-1_slack13.37.txz

+====================================================
| Upgrading pidgin-2.7.11-i486-1 package using
./pidgin-2.9.0-i486-1_slack13.37.txz
+====================================================

Pre-installing package pidgin-2.9.0-i486-1_slack13.37...

Removing package /var/log/packages/pidgin-2.7.11-i486
–1-upgraded-2011-09-02,09:16:53...
  --> Deleting /usr/doc/pidgin-2.7.11/AUTHORS
  --> Deleting /usr/doc/pidgin-2.7.11/COPYING
  --> Deleting /usr/doc/pidgin-2.7.11/COPYRIGHT
  --> Deleting /usr/doc/pidgin-2.7.11/HACKING
  --> Deleting /usr/doc/pidgin-2.7.11/INSTALL
  --> Deleting /usr/doc/pidgin-2.7.11/NEWS
  --> Deleting /usr/doc/pidgin-2.7.11/PLUGIN_HOWTO
  --> Deleting /usr/doc/pidgin-2.7.11/README
  --> Deleting /usr/doc/pidgin-2.7.11/README.MTN
  --> Deleting /usr/doc/pidgin-2.7.11/README.mingw
  --> Deleting /usr/doc/pidgin-2.7.11/doc/TracFooter...
  --> Deleting /usr/doc/pidgin-2.7.11/doc/TracHeader...
...
...
...
Verifying package pidgin-2.9.0-i486-1_slack13.37.txz.
Installing package pidgin-2.9.0-i486-1_slack13.37.txz:
PACKAGE DESCRIPTION:
# pidgin (GTK+ instant messaging program)
#
# Pidgin allows you to talk to anyone using a variety
# of messaging protocols, including AIM (Oscar and TOC),
# ICQ, IRC, Yahoo!, MSN Messenger, Jabber, Gadu-Gadu,
# Napster, and Zephyr.  These protocols are implemented
# using a modular, easy to use design.  To use a
# protocol, just load the plugin for it.
#
# For more info, see:  http://www.pidgin.im
#
Executing install script for pidgin-2.9.0-i486-1_slack13.37.txz.
Package pidgin-2.9.0-i486-1_slack13.37.txz installed.

Package pidgin-2.7.11-i486-1 upgraded with new package
./pidgin-2.9.0-i486-1_slack13.37.txz.

Paketinhalt entpacken

explodepkg

Der Inhalt eines Pakets lässt sich mit dem Programm explodepkg in das aktuelle Arbeitsverzeichnis entpacken. Dabei werden Skripte, die im Paket enthalten sind, nicht ausgeführt.

Alternativ kann man Slackware-Packages auch mit tar -xvzf Paket.tgz entpacken.

Pakete erstellen

makepkg

Sie können Slackware-Pakete mit dem Programm makepkg auch relativ einfach selbst erstellen. 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 Eigentümer sowie Gruppe root gesetzt werden.

Listing 14.33 makepkg erstellt das Package für MeinTool

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

slack-desc und doinst.sh

makepkg verwendet als Inhalt des Packages übrigens den Inhalt des aktuellen Arbeitsverzeichnisses. Darin sollte sich ein Verzeichnis namens install/ befinden, und in diesem wiederum eine Datei namens slack-desc, 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.

14.2.5 Gentoo Portage

Das Paketsystem von Gentoo ist dem BSD-Ports-System – auf das wir noch zu sprechen kommen werden – sehr ähnlich. Unter Gentoo Linux wird Software (sogenannte Ebuilds) 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.

emerge

Gesteuert wird das Gentoo Portage System über das Programm emerge, das sich darum kümmert, die einzelnen Ebuilds zu übersetzen, zu suchen, zu erneuern und zu installieren. Dabei werden auch Abhängigkeiten automatisch aufgelöst. Zusätzliche Informationen liefert Ihnen emerge generell mit der Option -v.

(De-)Installation

Möchte man ein Programm installieren, so ruft man emerge mit dessen Namen, also etwa mit emerge vim, auf. Mit emerge --depclean vim würde man das Programm hingegen wieder deinstallieren und mit emerge --depclean generell nicht mehr benötigte Abhängigkeiten entfernen.

Updates

Das Paketsystem kann durch einen Aufruf von emerge -auDN world auf den neuesten Stand gebracht werden, wobei vor dem Ersetzen einer Software durch eine neue Version nachgefragt wird (-a).

Software suchen

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

Portage updaten

Das Portage-Verzeichnis, das eine Liste der verfügbaren Ebuilds (und die Ebuilds selbst) enthält, lässt sich durch emerge --sync aktualisieren.

14.2.6 BSD-Ports

Nun kommen wir zu den bereits erwähnten Ports. Ports werden primär unter BSD-Systemen verwendet und sind nicht mit den Ports im Sinne von Portierungen zu verwechseln. Ein solcher 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 es, wechseltsystematisch 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 dann nicht, wenn Sie eine neuere Version der Ports herunterladen, denn sonst müssen 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 finden Sie auf dem FTP-Server von NetBSD, wobei die Datei pkgsrc.tar.gz geladen werden muss. [Fn. ftp.netbsd.org/pub/NetBSD/NetBSD-current/tar_files/] Diese entpackt man üblicherweise in das Verzeichnis /usr, in dessen Unterverzeichnis pkgsrc anschließend der Ports-Tree zu finden ist.

Listing 14.34 Laden und entpacken

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

Im pkgsrc-Verzeichnis finden Sie verschiedenste Unterverzeichnisse. Sie 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 ihrerseits Abhängigkeiten aufweisen, so werden diese ebenfalls heruntergeladen und so weiter.

Wollen Sie zum Beispiel KDE installieren, so benötigt Ihr System zunächst einmal diverse Bibliotheken und Programme, die ihrerseits 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 ist. [Fn. Falls Sie einen langsamen Rechner haben, sollten Sie nicht mit KDE anfangen, da dieser Übersetzungsvorgang dann durchaus mehrere Stunden dauern könnte.]

Nach dem Übersetzungsvorgang muss das jeweilige Paket noch vorkonfiguriert und installiert werden. Dies wird mit dem 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 beziehen Sie ebenfalls vom jeweiligen FTP-Server des Projekts als Archivdatei (ports.tar.gz). [Fn. ftp://ftp.openbsd.org/pub/OpenBSD/] Nachdem Sie diese Datei ebenfalls in /usr entpackt haben, wechseln Sie in das Verzeichnis ports. Dort finden Sie eine Verzeichnishierachie vor, die jener der NetBSD Package Collection sehr ähnlich ist. Der Vorgang zur Installation von Software wird auf dieselbe Weise bewerkstelligt wie unter NetBSD. Installieren wir beispielsweise einmal das KDE-3-Basissystem:

Listing 14.35 Den Port kde/base3 installieren

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

Sie können diesen Vorgang auch mit verketteten make-Aufrufen verkürzen:

Listing 14.36 Alias für make

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

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 der Aufbau etwas verschieden. Allerdings lässt sich ein allgemeiner Aufbau zumindest grob erläutern.

Im jeweiligen Port-Verzeichnis finden sich, wenn man vom Beispiel OpenBSD ausgeht, folgende wichtige Dateien:

CVS
Das CVS-Verzeichnis 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 die Namen der Dateien, die zu dieser Software gehören und installiert werden.

[+]Unter anderen Systemen haben die entsprechenden Dateien sehr ähnliche Namen, so heißt pkg-descr unter FreeBSD beispielsweise DESCR.

Listing 14.37 Wichtige Informationen am Beispiel von Sylpheed

# 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

Port-Management

Update

Das Port-Management gestaltet sich recht simpel. Ein Update des Ports-Trees wird durchgeführt, indem entweder eine neue Archivdatei der Ports vom jeweiligen Server geladen oder ein CVS-Update durchgeführt wird. [Fn. In Kapitel 30, »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.

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

Als erstes 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 müssen Sie die oft gepackt gelieferten Sourcen irgendwohin entpacken:

Listing 14.38 Entpacken eines Archivs

$ tar -xzf quellen.tar.gz

Im Normalfall gibt es dann ein neues Verzeichnis, in das man mit dem cd-Kommando wechseln kann. Dort 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:

Listing 14.39 Kompilieren von Quellcode

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

Das Paket wird zuerst mittels ./configure konfiguriert und dann mit make übersetzt. Schließlich kopiert man als root mit make install die fertigen Programme noch an die richtige Stelle des Dateisystems.

Standardmäßig werden selbst erstellte Programme nicht in die »normalen« Verzeichnisse wie /usr/bin kopiert, sondern in eine Extrahierarchie unter /usr/local. Die fertigen Binaries landen dann beispielsweise unter /usr/local/bin und die Manpages in /usr/local/man. Dies 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, so dass das Kompilieren auch dann keine allzu große Hürde mehr darstellt.

Das Vorgehen bei Problemen

Natürlich klappt nicht immer alles reibungslos. Im Folgenden wollen wir kurz die wichtigsten Fehler und deren Ursachen behandeln.

configure schlägt fehl

Mit configure konfigurieren wir das Paket. So 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 diese meist selbsterklärend.

Oft reicht es dann aus, wenn man zum Beispiel fehlende Bibliotheken einfach nachinstalliert, also sich noch einmal die Installations-CDs heranholt oder einfach mal ein apt-get install lib_die_fehlt ausprobiert. Zudem gibt es Include-Dateien, eine Art Inhaltsverzeichnis für Softwarebibliotheken. Dass configure solche Dateien nicht findet, hat in der Regel zwei Gründe:

Falsches Verzeichnis
Include-Dateien werden standardmäßig in bestimmten Verzeichnissen vermutet. Manchmal befinden sie sich aber woanders, beispielsweise wegen unpassender Versionsnummern oder aufgrund der Tatsache, dass es sich bei Ihrem System um eine andere Distribution als bei dem der Programmierer handelt und die Verzeichnisse etwas anders strukturiert sind. Setzen Sie doch einfach einen Link, oder kopieren Sie alles entsprechend an die richtige Stelle. Vielleicht muss auch nur eine Shellvariable 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 zwischen Bibliotheken für normale Systeme und Bibliotheken zum Programmieren. Dies 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 dann auch (ausgenommen man ist Informatiker) 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 dies 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

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

Name
E-Mail
Ihr Kommentar