Ein Softwarepaket ist eine Archivdatei, die ein Computerprogramm sowie die erforderlichen Metadaten für dessen Bereitstellung enthält. Das Computerprogramm kann im Quellcode vorliegen, der zunächst kompiliert und erstellt werden muss. Zu den Paket-Metadaten gehören die Paketbeschreibung, die Paketversion und die Abhängigkeiten (andere Pakete, die zuvor installiert werden müssen).
Paketmanager haben die Aufgabe, Softwarepakete auf Befehl des Benutzers zu finden, zu installieren, zu pflegen oder zu deinstallieren. Typische Funktionen eines Paketmanagementsystems sind:
- Arbeiten mit Dateiarchiven, um Paketarchive zu extrahieren
- Sicherstellen der Integrität und Authentizität des Pakets durch Überprüfen ihrer Prüfsummen bzw. digitalen Zertifikate
- Aufsuchen, Herunterladen, Installieren oder Aktualisieren vorhandener Software aus einem Software-Repository oder App-Store
- Gruppieren von Paketen nach Funktion, um die Verwirrung der Benutzer zu verringern
- Verwalten von Abhängigkeiten, um sicherzustellen, dass ein Paket mit allen benötigten Paketen installiert wird,
Herausforderungen bei gemeinsam genutzten BibliothekenBearbeiten
Computersysteme, die sich auf die dynamische Verknüpfung von Bibliotheken anstelle der statischen Verknüpfung von Bibliotheken stützen, nutzen ausführbare Bibliotheken mit Maschinenanweisungen gemeinsam für Pakete und Anwendungen. In diesen Systemen führen komplexe Beziehungen zwischen verschiedenen Paketen, die unterschiedliche Versionen von Bibliotheken benötigen, zu einer Herausforderung, die umgangssprachlich als „Abhängigkeitshölle“ bezeichnet wird. Auf Microsoft Windows-Systemen wird dies auch als „DLL-Hölle“ bezeichnet, wenn mit dynamisch verknüpften Bibliotheken gearbeitet wird. Eine gute Paketverwaltung ist auf diesen Systemen unerlässlich. Das Framework-System von OPENSTEP war ein Versuch, dieses Problem zu lösen, indem es ermöglichte, mehrere Versionen von Bibliotheken gleichzeitig zu installieren und für Softwarepakete anzugeben, gegen welche Version sie gelinkt wurden.
Front-Ends für lokal kompilierte PaketeBearbeiten
Systemadministratoren können Software mit anderen Werkzeugen als Paketverwaltungssoftware installieren und warten. Zum Beispiel kann ein lokaler Administrator ungepackten Quellcode herunterladen, kompilieren und installieren. Dies kann dazu führen, dass der Zustand des lokalen Systems nicht mehr mit dem Zustand der Datenbank des Paketmanagers synchronisiert ist. Der lokale Administrator muss dann zusätzliche Maßnahmen ergreifen, wie z.B. die manuelle Verwaltung einiger Abhängigkeiten oder die Integration der Änderungen in die Paketverwaltung.
Es gibt Werkzeuge, die sicherstellen, dass lokal kompilierte Pakete in die Paketverwaltung integriert werden. Für Distributionen, die auf .deb- und .rpm-Dateien basieren, sowie für Slackware Linux gibt es CheckInstall, und für rezeptbasierte Systeme wie Gentoo Linux und hybride Systeme wie Arch Linux ist es möglich, zunächst ein Rezept zu schreiben, das dann dafür sorgt, dass das Paket in die lokale Paketdatenbank passt.
Wartung der KonfigurationBearbeiten
Besonders lästig bei Software-Upgrades sind Upgrades von Konfigurationsdateien. Da Paketmanager, zumindest auf Unix-Systemen, als Erweiterungen von Dateiarchivierungsprogrammen entstanden sind, können sie Konfigurationsdateien in der Regel nur entweder überschreiben oder beibehalten, anstatt Regeln auf sie anzuwenden. Es gibt Ausnahmen, die normalerweise für die Kernelkonfiguration gelten (die, wenn sie beschädigt ist, den Computer nach einem Neustart unbrauchbar macht). Probleme können entstehen, wenn sich das Format von Konfigurationsdateien ändert; zum Beispiel, wenn die alte Konfigurationsdatei neue Optionen, die deaktiviert werden sollten, nicht explizit deaktiviert. Einige Paketmanager, wie z.B. dpkg von Debian, erlauben die Konfiguration während der Installation. In anderen Situationen ist es wünschenswert, Pakete mit der Standardkonfiguration zu installieren und diese Konfiguration dann zu überschreiben, zum Beispiel bei Headless-Installationen auf einer großen Anzahl von Computern. Diese Art der vorkonfigurierten Installation wird auch von dpkg unterstützt.
RepositoriesEdit
Um den Benutzern mehr Kontrolle über die Art der Software zu geben, die sie auf ihrem System installieren lassen (und manchmal aus rechtlichen Gründen oder aus Bequemlichkeitsgründen auf Seiten der Distributoren), wird Software oft von einer Reihe von Software-Repositories heruntergeladen.
Unterdrückung von UpgradesBearbeiten
Wenn ein Benutzer mit der Paketverwaltungssoftware interagiert, um ein Upgrade durchzuführen, ist es üblich, dem Benutzer die Liste der auszuführenden Aktionen zu präsentieren (normalerweise die Liste der zu aktualisierenden Pakete und möglicherweise die Angabe der alten und neuen Versionsnummern) und dem Benutzer die Möglichkeit zu geben, das Upgrade entweder als Ganzes zu akzeptieren oder einzelne Pakete für Upgrades auszuwählen. Viele Paketmanager können so konfiguriert werden, dass bestimmte Pakete nie aktualisiert werden oder dass sie nur dann aktualisiert werden, wenn in der vorherigen Version kritische Sicherheitslücken oder Instabilitäten gefunden werden, die vom Paketmanager der Software definiert wurden. Dieser Prozess wird manchmal als „Version Pinning“ bezeichnet.
Zum Beispiel:
- yum unterstützt dies mit der Syntax exclude=openoffice*
- pacman mit IgnorePkg= openoffice (um die Aktualisierung von openoffice in beiden Fällen zu unterdrücken)
- dpkg und dselect unterstützen dies teilweise durch das hold Flag in der Paketauswahl
- APT erweitert das hold-Flag durch den komplexen „pinning“-Mechanismus (Benutzer können ein Paket auch auf eine schwarze Liste setzen)
- aptitude hat „hold“- und „forbid“-Flags
- portage unterstützt dies durch das Paket.mask configuration file
Cascading package removalEdit
Einige der fortgeschritteneren Paketverwaltungsfunktionen bieten eine „kaskadierende Paketentfernung“, bei der alle Pakete, die von dem Zielpaket abhängen, und alle Pakete, von denen nur das Zielpaket abhängt, ebenfalls entfernt werden.
Vergleich der BefehleEdit
Obwohl die Befehle für jeden einzelnen Paketmanager spezifisch sind, sind sie weitgehend übersetzbar, da die meisten Paketmanager ähnliche Funktionen anbieten.
Action | zypper | pacman | apt | dnf (yum) | portage |
---|---|---|---|---|---|
Paket installieren | zypper in PKG |
pacman -S PACKAGE |
apt install PACKAGE |
dnf install PACKAGE |
emerge PACKAGE |
remove package | zypper rm -RU PKG |
pacman -R PACKAGE |
apt remove PACKAGE |
dnf remove --nodeps PACKAGE |
emerge -C PACKAGE oder emerge --unmerge PACKAGE |
remove package+orphans | zypper rm -u --force-resolution PKG |
pacman -Rs PACKAGE |
apt autoremove PACKAGE |
dnf remove PACKAGE |
emerge -c PACKAGE oder emerge --depclean PACKAGE |
update software database | zypper ref |
pacman -Sy |
apt update |
dnf check-update |
emerge --sync |
aktualisierbare Pakete anzeigen | zypper lu |
pacman -Qu |
apt list --upgradable |
dnf check-update |
emerge -avtuDN --with-bdeps=y @world oder emerge --update --pretend @world |
delete orphans+config | zypper rm -u |
pacman -Rsn $(pacman -Qdtq) |
apt autoremove |
dnf erase PKG |
emerge --depclean |
show orphans | zypper pa --orphaned --unneeded |
pacman -Qdt |
package-cleanup --quiet --leaves --exclude-bin |
emerge -caD oder emerge --depclean --pretend |
|
update all | zypper up |
pacman -Syu |
apt upgrade |
dnf update |
emerge --update --deep --with-bdeps=y @world |
Das Arch Linux Pacman/Rosetta wiki bietet eine umfangreiche Übersicht.