Paketmanagement

Um software zu installieren müssen bestimmte Dateien, Programme und Abhängigkeiten an bestimmte Stellen im System abgelegt werden. Zudem müssen oft noch weitere Schritte vorgenommen werden wie Einstellungen ändern, Benutzer anlegen und vieles mehr.

Damit der Benutzer nicht alles selbst machen muss gibt es grundsätzlich zwei Konzepte. Installer sind kleine Programme die einmal ausgeführt werden und sich um alles kümmern. Das war Jahrelang der Hauptweg um unter Windows Software zu installieren, kommt aber mit erheblichen Nachteilen. Zum einen muss der Nutzer die Software von fremden, potentiell virenbefallenen, Quellen Programme herunterladen, und zum anderen gibt es keine zentrale Stelle die weiß welche Software installiert ist.

Linux ist das Problem schon immer anders angegangen und Nutzt sogenannte Pakete. Pakete sind Archive mit sämtlichen notwendigen Dateien, Programmen, maschinenlesbaren (De-)Installationsanleitungen und Metadaten die automatisches Updaten, Dependency Management, und vieles mehr ermöglichen. Pakete lösen an sich zwar nicht das Problem mit fremden Quellen, bieten aber eine Zentrale Stelle im System die weiß, welche Pakete installiert wurden. Zudem ermöglichen Pakete eine Einheitliche Art und Weise mit Software umzugehen und sogenannte Repositories bereitzustellen. Repositories sind Vertrauenswürdige Quellen mit getesteter und gescannter Software. Das macht die Installation und das Management wesentlich einfacher.

Pakete

Pakete sind archive mit Dateien, Installationsanleitungen und Metadaten.

Debian

Wer selbst ein Paket bauen möchte, oder eins anschauen will, kann beliebige Pakete entpacken

dpkg-deb -R <FILE> <TARGET>  

und wieder verpacken

dpkg-deb --build   

.  
|-- DEBIAN  
|   |-- control  
|   |-- postinst  
|   |-- postrm  
|   |-- preinst  
|   `-- prerm  
`-- etc  
    `-- myapp  
        `-- test.txt  

Der Aufbau von Paketen ist immer ähnlich und Besteht aus einem DEBIAN ordner und weiteren Dateien. Die weiteren Dateien werden von dpkg so ins system gelegt wie sie im Paket sind. Wer also eine Datei namens test.txt in /etc/myapp ablegen will, muss die datei in ./etc/myapp/test.txt anlegen. Zusätzlich kann das packet die Skripte preinst, postinst, prerm und postrm enthalten. Sie werden jeweils vor (pre) und nach (post) der Installation (inst), beziehungsweise Deinstallation (rm) ausgeführt. Also bevor die Dateien an die entsprechenden stellen gelegt, beziehungsweise entfernt werden. Damit das klappt, müssen die Skripte ausführungsberechtigungen gesetzt haben.

Die control datei speichert die Metadaten des Packetes

Package: myapp  
Version: 1.0  
Section: utils  
Priority: optional  
Architecture: all  
Depends: python (>= 3.10), curl | wget  
Maintainer: John Doe <john.doe@theadminwiki.de>  
Description: My little test application  

Section ist frei wählbar, sollte sich aber an gängigen Sektionen der Distribution orientieren wie zum Beispiel:

Priorität gibt die wichtigkeit des Pakets für ein System an. Sie kann required, important, standard oder optional sein, ist aber in den aller meisten Fällen optional

Architekturue muss ein bekanntes Alias für die Architektur sein die unterstützt wird. Architekturunabhängige Pakete wie reine Dateien oder Python Skripte können all nutzen. Architekturabhängige Pakete sollten aus amd64, i386, arm64 oder armhf wählen. Im zweifel kennt das System die architektur selbst dpkg --print-architecture. Das wird auch genutzt um die Kompatibilität des Paketes zu ermitteln.

Depends listed alle Abhängigkeiten auf. Es können auch alternative Abhängigkeiten angegeben werden (curl | wget) und konkrete Versionen

Einfache Paketmanager

Einfache (low-level) Paketmanager kennen nur installierte Pakete und das, was gerade installiert werden soll. Sie Installieren, Deinstallieren und Konfigurieren Pakete. Um ein Paket zu installieren muss es erst heruntergeladen werden. Dabei stellen Paketmanager sicher dass bei der Installation alle notwendigen Abhängigkeiten installiert sind und bei der Deinstallation kein noch installiertes Paket vom deinstallierten Paket abhängt. Anderenfalls wirft der Paketmanager einen Fehler und listet die betroffenen Pakete auf.

DPKG

Debian Package (DPKG) ist ein low-level Package Manager der von Debian entwickelt wird und auch auf nahezu jedem Derivat (wie Ubuntu) zum Einsatz kommt.

RPM

RedHat Package Manager (RPM) ist ein low-level Package Manager von RedHat der auch auf nahezu jedem Derivat (wie Fedora) zum Einsatz kommt. Zudem wird RPM von SUSE verwendet, obwohl es kein RedHat Derivat ist.

Repository Basierte Paketmanager

Einfache Paketmanager kennen nur installierte Pakete und das, was gerade installiert werden soll. Sie können also prüfen ob alle Abhängigkeiten installiert sind, aber keine weiteren Pakete aus dem Nichts installieren. Repository basierte (high-level) Paketmanager erfinden das Rad nicht neu und bauen deshalb meist auf bereits bestehende einfachere Paketmanager auf.
Um Pakete zu verwalten reden sie mit den daruntergelegenen Paketmanagern, haben aber vollen Zugriff auf Repositories um nach fehlenden Abhängigkeiten zu suchen und diese einfach mit zu installieren. Die Repositories sind nich fest definiert. Stattdessen bieten Repository basierte Paketmanager eine Stelle an, an der Paketquellen hinterlegt sind.

Um nicht jedes mal das komplette Repositoryverzeichnis zu durchsuchen wird einmal ein Manifest heruntergeladen. Quasi eine Liste an verfügbaren Paketen, versionen und weiteren Metainformationen. Diese Liste kann sehr schnell veralten. Zum Beispiel, wenn ein neues Paket hinzugefügt wird, Software aktualisiert wird, oder eine Sicherheitslücke gepatched wird. Um sicherzugehen dass der Paketmanager immer über die aktuellsten Informationen verfügt kann es notwendig sein die Metadaten zu aktualisienen.

Ein weiterer wesentlicher Unterschied zu einfachen Paketmanagern ist, dass sich Repository basierte Paketmanager selbst um Abhängigkeiten kümmern. In seltenen fällen, vor allem in verbindung mit einigen Befehlen die --force oder -f beinhalten, aber auch bei Systemabstürzen oder anderen Problemen, kann es zu inkonsistenzen kommen. Abhängigkeiten fehlen oder sind in der falschen Version vorhanden. In dem fall ist es oft hilfreich die Systemkonsistenz wiederherzustellen.

APT

APT und apt-get basieren auf DPKG Beide sind sehr beliebt in Debian basierten Systemen. apt-get ist älter und verändert sich heute kaum noch. Daher wird es primär in skripten verwendet, da man dort ein stabiles Interface braucht. apt ist ein modernen Makeover von apt-get`, vereint mehrere Tools die um apt-get herum gebaut wurden und bietet ein angenehmeres Interface. Da sich apt aber keinem stabilen Interface verschrieben hat wird abgeraten es in Skripten zu verwenden.

Cache Dateien liegen unter /var/cache/apt/archives.

Repository Management

Quellen für apt und apt-get wurden in /etc/apt/sources.list definiert, allerdings werden heute zur besseren Übersicht fast nurnoch .list Dateien in /etc/apt/sources.list.d/ genutzt. Beide Paketmanager respektieren aber beide Wege. Um Quellen zu definieren gibt es zwei formate innerhalb dieser Dateien. APT kommt mit beiden klar, allerdings präferieren manche Distributionen das ein oder andere. Beide formate definieren den Typ der Pakete, meist deb, URIs zum Repository, meist ftp oder http, Suites und Components zum logischen Trennen von Paketen und optional einen GPG Key der die Signatur der Pakete prüfen kann.

 deb  http://de.archive.ubuntu.com/ubuntu noble main restricted universe multiverse  
^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  
TYPE                URI                   SUITE             COMPONENTS  
  
 deb [signed-by=/usr/share/keyring/ubuntu-archive-keyring.gpg] http://de.archive.ubuntu.com/ubuntu noble main restricted universe multiverse  
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  
                        GPG KEY  

Mit der klassischen Syntax kann man nur eine Suite angeben. Will man aus dem selben Repository mehrere Suites nutzen, braucht es mehrere Zeilen. Zudem ist die Syntax eher unübersichtlich. Die Deb822 Syntax löst das Problem.

Types: deb  
URIs: http://de.archive.ubuntu.com/ubuntu  
Suites: noble noble-updates noble-backports  
Components: main restricted universe multiverse  
Signed-By: /usr/share/keyring/ubuntu-archive-keyring.gpg  

Suites und Components können von den Repositories frei gewählt werden, Debian und Ubuntu haben aber Standards, die von den meisten Repositories respektiert werden.

Als Suite nutzen Ubuntu und Debian den Codename der Version (z.B. noble) und zusätzlich ein suffix zum trennen von Updatezyklen.

Als Komponenten Nutzt Ubuntu folgendes Schema

Debian unterscheidet nicht zwischen den Maintainern, aber granularer zwischen der Quelloffenheit.

YUM, DNF

YUM und DNF basieren auf RPM. YellowDog Updater (YUP) wurde damals für die (heute nicht mehr existente) YellowDog Linux Distribution geschrieben. Da YellowDog Linux ein RedHat Derivat war und YUP an sich gute Software, modifizierte RedHat YUP um es auf alle RedHat Derivate portieren zu können und veröffentlichte den Paketmanager als YellowDog Updater, Modified (YUM). Beide Manager wurden in Python2 geschrieben, was heute veraltet ist. Als ersatz wurde YUM in Python3 neu geschrieben und als Dandified YUM (DNF) von RedHat veröffentlicht. Der Befehl yum ist zwar heute noch auf einigen RedHat Derivaten, ist aber ein wrapper um DNF und nutzt daher die DNF-Syntax.

Cache Dateien liegen unter /var/cache/yum, beziehungsweise in /var/cache/dnf.

Repository Management

Quellen für YUM und DNF befinden sich in .repo Dateien in /etc/yum.repos.d/. Allerdings werden repositories durch den config-manager verwaltet. Die Nutzung wurde in DNF Version 5 jedoch deutlich verändert.

Zypper

Zypper wurde von SUSE entwickelt. SUSE Systeme nutzen zwar ebenfalls RPM Pakete, die Repositories sind aber vollkommen anders aufgebaut und fordern daher einen eigenen Manager.

Cache Dateien liegen unter /var/cache/zypp.

Repository Management

Quellen für YUM und DNF befinden sich in .repo Dateien in /etc/zypp/repos.d/. Allerdings werden repositories durch zypper direkt verwaltet. Zudem kann pro repository eingestellt werden ob beim Nutzen des Repositories automatisch die neuen Metainformatiionen geholt werden sollen. Damit sollte man allerdings vorsichtig sein, da dass den gesamten Prozess deutlich verlangsamen und zu erhöhtem Resourcenverbrauch führen kann.

Containerbasierte Paketmanager

Containerbasierte Paketmanager haben das Ziel komplett unabhängig von der Distribution zu sein und damit eine leichtere Verteilung von Software zu ermöglichen. Das wird erreicht indem zur eigentlichen Software auch noch die meisten Dependencies gepackt wird. Zudem wird die Software in einem Container (Sandbox) gestartet um unabhängiger von der Distribution zu laufen und einen Zusätzlichen Schutzmechanismus zu bieten. Containerbasierte Paketmanager basieren meist auf einen Hintergrundprozess der unter anderem automatisch nach Updates suchen kann.

Vorteile sind dass die Anwendung fast überall läuft, unabhängig von der Linux Distribution. Kein Dependency Management braucht und somit schnell und einfach installiert ist. Mehrere Versionen gleichzeitig unterstützt, da die Pakete erst in der Sandbox ausgepackt werden. Automatische Updates durch den Hintergrundprozessprozess.
Die Nachteile solcher Pakete sind Riesige Pakete aufgrund aller Dependencies in dem Paket. Das ist vor allem dann Spürbar, wenn man zum fünften mal die selbe Grafikbibliothek installiert die jede GUI braucht. Langsamerer Start und Höherer Speicherbedarf durch die Sandbox und das einrichten der Umgebung.

Snap

Snap ist ein Paketmanager von Ubuntu. Durch die einfache verteilung von Software ist die Nutzung ebenfalls entsprechend einfach. Der Befehl snap redet mit dem Hintergrundprozess snapd, der dann die Suche, Installation und Updates durchführt.

Flatpak

Flatpak ist eine alternative zu Snap von RedHat mit freier Quellenwahl und viel mehr Unterstützung in einer Vielzahl an Distributionen die nicht nur zu RedHat gehören.

Flatpak verwendet sogenannte Remotes, die als Softwarequellen dienen. Diese können hinzugefügt oder entfernt werden. Der wichtigste Remote ist Flathub, welcher eine große Sammlung an Desktop-Anwendungen bereitstellt.

Beispiel zum Hinzufügen von Flathub:

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo