Paketverwaltung ist eine der am häufigsten nachgefragten Erweiterungen für das LFS-Buch. Mit einer Paketverwaltung können Sie die Installation von Dateien protokollieren und diese dann später leicht wieder deinstallieren oder Pakete aktualisieren. Ein Paketmanager kümmert sich grundsätzlich nicht nur um ausführbare Binärdateien und Bibliotheken, sondern auch um Einrichtungsdateien. Vorab erstmal eine Klarstellung: NEIN — dieses Kapitel behandelt keine Paketverwaltung im Detail und wird Ihnen auch keine empfehlen. Sie werden hier nur Informationen zu den am weitesten verbreiteten Methoden und Techniken erhalten. Die für Sie perfekte Paketverwaltung könnte dabei sein, vielleicht ist es auch eine Kombination aus zwei oder mehr Techniken.
Einige Gründe, warum weder in LFS noch in BLFS eine Paketverwaltung installiert wird, sind:
Der Umgang mit einer Paketverwaltung lenkt die Aufmerksamkeit vom eigentlichen Ziel des Buches ab — nämlich zu lernen, wie man ein Linux-System von Hand erstellt.
Es gibt viele Paketverwaltungen; jede hat ihre Vor- und Nachteile. Es ist schwierig, eine zu finden, die alle Leser zufriedenstellen würde.
Es wurden einige Tipps zu diesem Thema geschrieben. Lesen Sie im Hints-Projekt nach, vielleicht finden Sie eine passende Paketverwaltung für Sie.
Mit einer Paketverwaltung ist es recht einfach, ein Paket zu aktualisieren. Grundsätzlich kann man aber auch die Anleitungen in LFS und BLFS zur Aktualisierung auf neuere Versionen verwenden. Im Folgenden finden Sie allerdings ein paar wichtige Dinge, die Sie beim Aktualisierungen von Programmen beachten sollten (insbesondere auf einem laufenden System).
Wenn eines der Toolchain-Pakete (Glibc, GCC oder Binutils) auf eine neue Minor-Version aktualisiert werden muss, ist es meist besser, LFS neu zu installieren. Es ist möglich, dass einfaches Neuinstallieren der betroffenen Pakete in der richtigen Abhängigkeitsreihenfolge ausreicht, aber davon wird dringend abgeraten! Wenn Sie also z. B. glibc-2.2.x auf glibc-2.3.x aktualisieren müssen, sollten Sie neu installieren. Die Aktualisierung innerhalb einer Mikro-Version ist normalerweise problemlos möglich, wenn auch nicht zu 100% garantiert. Beispielsweise sollte ein Versionsupdate von glibc-2.3.4 auf glibc-2.3.5 keine Schwierigkeiten bereiten.
Wenn Sie ein Paket aktualisieren, das gemeinsam verwendete
Bibliotheken enthält und sich mit der Aktualisierung der Name
der Bibliothek ändert, dann müssen alle Programme, die die
Bibliothek verwenden, neu kompiliert werden. (Beachten Sie:
zwischen dem Namen der Bibliothek und der Paketversion
besteht grundsätzlich kein Zusammenhang.) Angenommen Sie
haben das Paket foo-1.2.3 mit der gemeinsamen Bibliothek
libfoo.so.1
. Dieses Paket
aktualisieren Sie nun auf Version 1.2.4, welche die
Bibliothek namens libfoo.so.2
installiert. In diesem Fall müssen Sie alle Programme neu
kompilieren, die libfoo.so.1
verwenden, damit sie in Zukunft libfoo.so.2
referenzieren. Beachten Sie
auch: Sie dürfen die alte Bibliothek erst entfernen, wenn
alle davon abhängigen Pakete aktualisiert wurden.
Im Folgenden werden einige Techniken zur Paketverwaltung beschrieben. Bevor Sie sich für eine entscheiden, informieren Sie sich bitte über die jeweilige Technik, insbesondere über die möglichen Nachteile.
Ja, auch das ist eine Methode der Paketverwaltung. Manche Leute benötigen einfach keine Software zur Paketverwaltung, weil sie alle Pakete gut kennen und wissen, welche Dateien vom jeweiligen Paket installiert werden. Andere Leute benötigen möglicherweise keine Paketverwaltung, weil sie LFS neu installieren, sobald ein Paket geändert wird.
Diese einfache Methode der Paketverwaltung benötigt keine weitere
Software. Jedes Paket wird einfach in einen eigenen Ordner
installiert. Beispielsweise wird foo-1.1 in den Ordner
/usr/pkg/foo-1.1
installiert und
dann einen symbolischen Link von /usr/pkg/foo
nach /usr/pkg/foo-1.1
angelegt. Wenn später auf die
neuere Version foo-1.2 aktualisiert wird, so erfolgt die
Installation in den Ordner /usr/pkg/foo-1.2
und der symbolischen Link wird
einfach durch einen neuen ersetzt.
Umgebungsvariablen wie PATH
,
LD_LIBRARY_PATH
, MANPATH
, INFOPATH
und
CPPFLAGS
müssen so angepasst werden,
dass Sie /usr/pkg/foo
enthalten.
Diese Methode wird sehr unhandlich, wenn auf diese Weise viele
Softwarepakete verwaltet werden sollen.
Es handelt sich hierbei im Grunde nur um eine Variation der
vorigen Paketverwaltungs-Technik. Jedes Paket wird genauso
installiert wie zuvor beschrieben. Anstatt jedoch den ganzen
Ordner mit einem Symlink zu versehen, wird für jede einzelne
Datei eine Verknüpfung in /usr
angelegt. Auf diese Weise müssen die Umgebungsvariablen nicht
angepasst werden. Die vielen symbolischen Verknüpfungen können
natürlich vom Benutzer selbst angelegt werden, jedoch gibt es
auch einige Programme dafür, die diese Technik verwenden: Stow,
Epkg, Graft und Depot sind einige Beispiele.
Die Installation muss allerdings so angepasst werden, so dass das
Paket "denkt", es wäre in /usr
installiert, obwohl die Dateien tatsächlich in /usr/pkg
gespeichert werden. Das vortäuschen
einer solchen Installation ist manchmal nicht ganz leicht. Nehmen
wir an, Sie möchten das Paket libfoo-1.1 installieren. Die
folgenden Kommandos würden das Paket nicht korrekt installieren:
./configure --prefix=/usr/pkg/libfoo/1.1 make make install
Die Installation ansich wird funktionieren, aber die abhängigen
Pakete werden nicht korrekt auf libfoo verweisen. Wenn Sie ein
Paket kompilieren, welches libfoo benötigt, so wird es gegen
/usr/pkg/libfoo/1.1/lib/libfoo.so.1
linken, anstatt den korrekten Pfad /usr/lib/libfoo.so.1
zu verwenden. Der korrekte
Ansatz ist der Einsatz der Variable DESTDIR
, mit der die Installation in einen anderen
Ordner vorgetäuscht werden kann. Dies funktioniert wie folgt:
./configure --prefix=/usr make make DESTDIR=/usr/pkg/libfoo/1.1 install
Diese Methode funktioniert mit den meisten Softwarepaketen, aber
leider nicht mit allen. Die inkompatiblen Pakete müssen Sie
entweder von Hand installieren, oder Sie installieren sie
unterhalb von /opt
.
Bei dieser Technik wird jede Datei vor der Installation mit einem Zeitstempel versehen. Nach der Installation können alle installierten Dateien mit einem einfachen find-Kommando gefunden und protokolliert werden. Die Paketverwaltung "install-log" setzt diese Methode ein.
Obwohl diese Methode natürlich sehr einfach ist, hat sie leider zwei Nachteile. Wenn während der Installation Dateien ohne oder mit einem anderen Zeitstempel als der aktuellen Zeit installiert werden, so wird deren Installation nicht protokolliert. Des Weiteren kann diese Methode nur funktionieren, wenn maximal ein Paket zur gleichen Zeit installiert wird. Das Protokoll ist nicht mehr zuverlässig, wenn z. B. auf einer anderen Konsole ein weiteres Programm zeitgleich installiert wird.
Bei diesem Ansatz werden alle Kommandos aufgezeichnet, die ein Installationsskript aufruft. Es gibt zwei mögliche Techniken, die Sie verwenden können:
Die Umgebungsvariable LD_PRELOAD
kann
auf eine Bibliothek verweisen, die vor der Installation geladen
werden soll. Während der Installation protokolliert diese
Bibliothek alle Installationsvorgänge mit, indem sie sich an
verschiedene ausführbare Programme wie cp, install und mv ahängt und die Systemaufrufe
mitverfolgt. Damit dies funktionieren kann, müssen alle
ausführbaren Programme dynamisch verlinkt und weder mit dem suid-
noch dem sgid-Bit versehen sein. Das Vorladen der Bibliothek kann
unter Umständen auch Nebeneffekte bei der Installation
hervorrufen. Deshalb sollten Sie diese Methode ausführlich
testen, bevor Sie sie produktiv einsetzen.
Bei dem zweiten Ansatz wird strace verwendet, um alle Systemaufrufe zu protokollieren, die während der Installation ausgeführt werden.
Bei dieser Methode wird die Installation in einem separaten Unterordner vorgenommen, ähnlich wie bei der Methode mit symbolischen Verknüpfungen. Nach der Installation wird aus der Ordnerstruktur ein Archiv mit den installierten Dateien erzeugt. Dieses Archiv kann dann zur Installation benutzt werden. Auf diese Weise können Sie ein Archiv auch auf mehreren Rechnern installieren.
Diese Methode kommt in den meisten kommerziellen Distributionen zum Einsatz. Beispiele für Paketverwaltungen, die diese Methode einsetzen, sind: RPM (welches im Übrigen von der Linux Standard Base Spezifikation erfordert wird), pkg-utils, Debians apt und Gentoos Portage-System. Eine Anleitung zur Verwendung dieses Paketverwaltungs-Systems finden Sie unter http://www.linuxfromscratch.org/hints/downloads/files/fakeroot.txt.
Diese für LFS einmalige Methode hat sich Matthias Benkmann ausgedacht. Informationen dazu finden Sie im Hints-Projekt. Bei der Benutzerbasierten Paketverwaltung wird jedes Paket unter Verwendung einer eigenen Benutzer-ID an den Standard-Installationsort installiert. Alle zu einem Paket gehörenden Dateien können anhand der Benutzer-ID leicht wiedergefunden werden. Die Vor- und Nachteile dieser Paketverwaltung sind allerdings so umfangreich, dass wir sie hier in diesem Kapitel nicht alle beschreiben können. Alle notwendigen Informationen finden Sie unter http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt.