Linux-Magazin Clean Linux (Vorschau)

en Score, da viele Pakete vom Notification‐Daemon
abhängen, es aber kein echtes
Paket dafür gibt. Eine weitere Rolle
spielen die Wünsche des Users: Wählt
er ein Paket explizit zur Installation oder
zum Löschen aus, steigt der Wert, um
den Wunsch zu berücksichtigen.
Löschen oder behalten
Ist die Wertigkeit der Pakete festgestellt,
beginnt die eigentliche Arbeit des Problem-Resolvers.
Er iteriert über die nach
Punkten sortierten Pakete. Trifft er auf
nicht erfüllte Abhängigkeiten oder Konflikte,
übernimmt Apt und prüft die am
stärksten betroffenen Exemplare einzeln.
Es versucht nicht erfüllte Abhängigkeiten
mit Hilfe von »keep« oder »delete« zu lösen.
Bleibt dies erfolglos, versucht Apt als
Nächstes, das Paket mit den nicht erfüllten
Abhängigkeiten zurückzuhalten oder
zu löschen. Dies wiederholt es so lange,
bis der Paket-Cache einen konsistenten
Zustand erreicht.
Listing 2 zeigt den Problem-Resolver von
Ubuntu 12.04 in einer Pbuilder-Chroot-
Umgebung bei der Arbeit. Hier lässt sich
gut beobachten, wie das Löschen von
»dpkg‐dev« dazu führt, dass das ebenfalls
installierte Paket »build‐essential« jetzt
eine verletzte Abhängigkeit aufweist (es
hängt von »dpkg‐dev« ab). Der Resolver
entscheidet daraufhin »build‐essential«
ebenfalls zu löschen, um das System
wieder in einen konsistenten Zustand zu
versetzen.
Die Zahlen »10001« hinter »dpkg‐dev« und
»0« hinter »build‐essential« geben jeweils
die Wertigkeit des Pakets an. Der hohe
Wert von »dpkg‐dev« rührt daher, dass
ein expliziter Wunsch des Users existiert,
das Paket zu löschen: Der Problemlöser
verändert seinen Zustand daher nicht,
sondern passt vielmehr die anderen Pakete
mit niedrigerer Wertigkeit an.
Auf los! geht’s los
Befindet sich der Cache endlich in einem
konsistenten Zustand, pflegt Apt die Änderungen
ein. Hierzu unterteilt das Tool
die Installation in die Schritte »remove«,
»unpack« und »configure«, um dann
»dpkg« für die einzelnen Pakete aufzurufen.
Dabei fasst Apt Pakete in Gruppen
zusammen, sodass sich »dpkg« auf größere
Gruppen von ihnen anwenden lässt,
was die Installation beschleunigt. Dank
der Option »‐o Debug::pkgDpkgPM=1«
kann ein Admin im Vorfeld verfolgen,
was »dpkg« tun würde.
In Listing 3 lässt sich beobachten, dass
Apt »dpkg« aufruft und damit explizit
die Architektur im Paketnamen angibt,
um auf einem Multiarchitektur-System
eindeutige Paketnamen zu erzeugen.
Spezialfälle
Für Ubuntu gibt es zusätzlich das Paket
»ubuntu‐release‐upgrader«. Es bringt das
Kommando »sudo do‐release‐upgrade«
mit, über das ein Ubuntu-Nutzer sein
System auf eine neue Version aktualisiert.
Ergänzt er die Option »‐‐devel«, springt
Ubuntu auf die Entwicklungsversion,
zurzeit die 13.10.
Der Release-Upgrader übernimmt Aufgaben,
die sonst ein Admin erledigen
müsste, etwa das Aktualisieren der Konfigurationsdatei
für die Paketquellen
(»/etc/apt/sources.list«). Zudem löst er
Sonderfälle beim Berechnen der Aktualisierung.
So stellt er sicher, dass auf
einem Desktop-Ubuntu stets das Metapaket
»ubuntu‐desktop« existiert.
Daneben deckt der Release-Upgrader Spezialfälle
ab. Ein solcher tritt zum Beispiel
ein, wenn ein Nutzer vom proprietären
»fglrx«- auf den freien »ati«-Grafikkartentreiber
wechselt, weil die neue Version
des proprietären Treibers die Hardware
des Rechners nicht mehr unterstützt. Intern
benutzt der Release-Upgrader die
Bibliothek Libapt, um das Upgrade zu
berechnen und Konflikte zu lösen.
Unattended Upgrades
Ein weiterer Spezialfall entsteht mit dem
Wunsch, Updates automatisch vom System
installieren zu lassen. Dafür sorgen
Unattended Upgrades – wenn man sie
entsprechend einrichtet. Sie installieren
meist Sicherheitsupdates für stabile Versionen
von Debian oder Ubuntu. Automatische
Sicherheitsupdates sind per
sudo dpkg‐reconfigure ‐plow unattendedU
‐upgrades
zu aktivieren. Es gibt noch weitere Konfigurationsoptionen,
die der Admin in der
Datei »/etc/apt/apt.conf.d/50unattended
‐up grades« einrichtet. Mehr Informationen
zum Thema Paketmanager gibt der
Artikel zu Beginn des Schwerpunkts.
Apt plus Python
Neben den Debug-Optionen für »apt‐get«
lässt sich nicht zuletzt mittels »python‐apt«
genau beobachten, wie das
System arbeitet. Das Skript aus Listing
4 verdeutlicht dies, indem es »Problem‐
Resolver« aktiviert (Zeile 3), das Paket
»dbus« löscht (Zeile 6), die kaputten Abhängigkeiten
im Cache betrachtet (Zeile
7) und den »ProblemResolver« erneut
startet, um das Hindernis zu beseitigen
(Zeile 9). Ein finaler Check (Zeile 10)
zeigt, dass der Cache keine kaputten Pakete
mehr enthält. (kki)
n
Der Autor
Michael Vogt ist seit dem Jahr 2000 Debian-
Entwickler und seit 2004 bei Ubuntu als Core
Developer aktiv. Arbeitet er mal nicht an einem
Programmierprojekt wie Apt, Python-apt,
Software-Center, Synaptic oder Unattended Upgrades,
trinkt er mit Vorliebe grünen Tee oder
spielt Hockey.
Listing 3: Apt löscht
01 $ apt‐get remove ‐o Debug::pkgDpkgPM=true dpkg‐dev
02 Reading package lists... Done
03 Building dependency tree
04 Reading state information... Done
05 The following packages will be REMOVED:
06 build‐essential dpkg‐dev
07 0 upgraded, 0 newly installed, 2 to remove and 0 not
upgraded.
08 After this operation, 1228 kB disk space will be
freed.
09 Do you want to continue [Y/n]?
10 /usr/bin/dpkg ‐‐status‐fd 57 ‐‐force‐depends
‐‐force‐remove‐essential ‐‐remove
build‐essential:amd64 dpkg‐dev:all
Listing 4: Python und Apt
01 #!/usr/bin/python
02 import apt
03 apt.apt_pkg.config.set("Debug::pkgProblemResolver"
, "1")
04 cache = apt.Cache()
05 pkgname="dbus"
06 cache[pkgname].mark_delete(auto_fix=False)
07 print cache.broken_count
08 resolver=apt.cache.ProblemResolver(cache)
09 resolver.resolve()
10 print cache.broken_count
Apt intern 09/2013
Titelthema
www.linux-magazin.de
33