Linux-Magazin Clean Linux (Vorschau)

Titelthema
www.linux-magazin.de Apt intern 09/2013
32
Der Problem-Resolver weist jedem Paket
einen Punktewert zu (Score), der seine
Wichtigkeit ausdrückt. Eine hohe Zahl
verweist auf ein wichtiges Paket. Um die
Scores einzelner Pakete zu betrachten,
ruft man die Option »‐o Debug::pkgProblemResolver::ShowScores=true«
auf. Die
Berechnung dieses Wertes ist relativ kompliziert,
denn es fließen einige Faktoren
ein wie die Priority und das »Essential:
yes«-Flag. Auch erhalten installierte Pakete
eine höhere Priorität.
Als Nächstes wird untersucht, wie viele
andere Pakete ein bestimmtes Paket als
Abhängigkeiten voraussetzen (Reverse
Dependencies). Jede Abhängigkeit erhöht
den Score. Dies stellt sicher, dass zentrale
Bibliotheken einen hohen Stellenwert erhalten.
So hat etwa die »libgcc1« auf einem
typischen Desktop einen Wert von
mehr als 2000.
An dieser Stelle werden auch Provides
berücksichtigt. Zum Beispiel erhalten
Pakete, die den »notification‐daemon« in
ihrer Provides-Liste führen, einen höheinstalliert
solche Pakete, indem er die Option
»‐‐install‐suggests« aktiviert, und
sudo apt‐get install ‐‐install‐suggests
‐‐fix‐policy
schaut nach, welche »suggests« auf dem
System fehlen – in der Regel sind das
recht viele.
Kommt es zu Konflikten, wird zwischen
Conflicts und Breaks unterschieden. Ein
Konflikt tritt auf, wenn sich zwei Pakete,
die identische Dateien enthalten, zur selben
Zeit auf dem Dateisystem befinden,
etwa »/usr/sbin/sendmail«. Ein Break
weist auf einen schwächeren Konflikt
hin: Er tritt auf, wenn sich zwei Pakete
zur gleichen Zeit im Installed-Zustand
befinden – unpacked dürfen sie hingegen
sein.
Typischerweise nutzen Breaks eine Versionsnummer,
zum Beispiel »Break: foo
( ( devel )
08 Broken build‐essential:amd64 Depends on dpkg‐dev [
amd64 ] < 1.16.1.2ubuntu7.1 > ( utils ) (>= 1.13.5)
09 Considering dpkg‐dev:amd64 10001 as a solution to
build‐essential:amd64 0
10 Removing build‐essential:amd64 rather than change
dpkg‐dev:amd64
11 Done
ändert, wodurch es für ältere Versionen
anderer Software, die dieses Interface
ebenfalls nutzen, unbenutzbar wird. Apt
versucht daher im obigen Beispiel, das
Paket »foo« auf eine Version 1.0 oder
besser zu aktualisieren.
Installation und Upgrades
Gibt der User eine Installation oder ein
Upgrade in Auftrag, schaut Apt zunächst
in seinem Cache nach, ob es den Paketnamen
kennt. Abhängig von der Policy
wählt es die Candidate-Version aus und
markiert diese für eine Installation oder
ein Upgrade. Als Nächstes iteriert Apt
über die Liste der Abhängigkeiten und
markiert alle noch nicht erfüllten oder
neuen Abhängigkeiten zur Installation.
Alle negativen Abhängigkeiten (wie
Conflicts und Breaks) markiert es zum
Löschen.
Der Admin kann Apt bei diesem Teil
der Arbeit beobachten, indem er das
Flag »‐o Debug::pkgDepCache::Auto Install=true«
setzt. Listing 1 visualisiert
über die eingerückten »Installing«-
Anweisungen, wie Libapt die Abhängigkeiten
auflöst, indem sie Schritt für
Schritt den Abhängigkeitsbaum durchwandert.
Noch weitere Details fördert
»-o Debug::pkgDepCache::Marker=1«
zutage.
Anders als bei einer Installation betrifft
ein Upgrade meist eine große Zahl von
Paketen. Das Kommandozeilentool
Apt‐get unterscheidet zwei Arten von
Upgrades: »sudo apt‐get upgrade« installiert
alle neuen Versionen von Software,
die nicht die Installation oder das Löschen
weiterer Pakete erfordern. Beim
Kommando »sudo apt‐get dist‐upgrade«
gibt es diese Einschränkung nicht. Weil
etwa ein neuer Kernel aufgrund von ABI-
Änderungen auch die stabilen Varianten
neuer Pakete einfordert, ist ein »sudo
apt‐get dist‐upgrade« für Upgrades im
Allgemeinen die bessere Wahl.
Der Algorithmus für »upgrade« arbeitet
sehr einfach: Er iteriert über alle installierten
Pakete und markiert sie für ein
Upgrade, wobei er die Option »AutoInstall«
explizit ausklammert. Der »ProblemResolver«
setzt dann problematische
Abhängigkeit zurück auf »keep«.
Der Algorithmus für »dist‐upgrade« arbeitet
ähnlich, allerdings nutzt er »AutoInstall«,
um neue Abhängigkeiten zu
installieren. Auch neue Pakete vom Typ
»Essential: yes« landen damit auf dem
Rechner. Anschließend startet der »ProblemResolver«,
um die verbleibenden
fehlerhaften Abhängigkeiten in Ordnung
zu bringen.
Der Problemlöser
Operationen wie »install«, »dist‐upgrade«
oder »remove« führen unter Umständen
dazu, dass der Cache inkonsistent wird,
das heißt, Abhängigkeiten verletzt oder
Konflikte nicht aufgelöst werden. Dies
kann zum Beispiel passieren, wenn die
Installation von Paket A ein Paket B installiert,
das in Konflikt mit einem bereits
installierten Paket steht.
An dieser Stelle kommt der so genannte
Problem-Resolver von Apt ins Spiel. Er
soll eine Lösung für die Inkonsistenzen
finden, seine Handlungen lassen sich über
»‐o Debug::pkgProblemResolver=true«
beobachten. Neben dem Problem-Resolver
gibt es noch weitere Implementierungen:
So bringt Aptitude eine eigene
Variante mit, daneben gibt es externe
Tools wie »aspcud«.
Pakete mit Punkten