{"id":3301,"date":"2016-07-13T19:47:16","date_gmt":"2016-07-13T17:47:16","guid":{"rendered":"http:\/\/speefak.spdns.de\/oss_lifestyle\/?p=3301"},"modified":"2024-06-02T13:52:40","modified_gmt":"2024-06-02T11:52:40","slug":"paketmanagement-grundlagen","status":"publish","type":"post","link":"https:\/\/speefak.spdns.de\/oss_lifestyle\/paketmanagement-grundlagen\/","title":{"rendered":"Paketmanagement – Grundlagen"},"content":{"rendered":"\n\n\n\n\n\n\n\n\n
\n

Grundlagen<\/a><\/h2>\n<\/td>\n

\n

Konfiguration<\/h2>\n<\/td>\n

\n

Anwendungen<\/h2>\n<\/td>\n<\/tr>\n

Paketformate<\/a><\/td>\n<\/td>\nBefehle – Zypper \/ APT (Shell)<\/a><\/td>\n<\/tr>\n
Paketverwaltungsbestandteile<\/a><\/td>\n<\/td>\nBefehle – Packagekit (Shell)<\/a><\/td>\n<\/tr>\n
PackageKit<\/a><\/td>\n<\/td>\nSynaptic – APT\/DEB (GUI)<\/a><\/td>\n<\/tr>\n
Komplexit\u00e4t<\/a><\/td>\n<\/td>\nYaST – YUM\/RPM (GUI)<\/a><\/td>\n<\/tr>\n
Fazit<\/a><\/td>\n<\/td>\n<\/td>\n<\/tr>\n
———————————————-<\/td>\n———————————————-<\/td>\n———————————————-<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 <\/p>\n

Grundlagen<\/span><\/h2>\n

Paketformate<\/h2>\n

F\u00fcr viele ist das Paketformat<\/em> und die Paketverwaltung<\/em> quasi identisch. Technisch gesehen ist das aber keineswegs so. Zum Einen gibt es das Paketformat, also das Dateiformat, welches die Software-Daten und Metainformationen enth\u00e4lt, sowie die Software, welche dieses Format einliest und verwaltet. Zum Anderen existiert der Paketmanager, welcher f\u00fcr das Interpretieren der Paket-Metainformationen (Abh\u00e4ngigkeiten, Konflikte, etc.) und f\u00fcr diverse Hilfsaufgaben (z.B. Repositories, Updates) zust\u00e4ndig ist.<\/p>\n

Ein Paketformat w\u00e4re z.B. RPM<\/a>, die Paketverwaltung und das zugeh\u00f6rige Tool hei\u00dfen ebenfalls RPM. F\u00fcr RPM gibt es nun diverse Paketmanager, wie z.B. die textbasierenden Werkzeuge Yum oder Zypper, oder auch grafische Werkzeuge wie YaST<\/a>. Bei Debian hingegen w\u00e4re das Paketformat DEB<\/a>\/DPKG<\/a>, der textbasierende Paketmanager jedoch APT<\/a> und als grafisches Frontend w\u00e4re hier Synaptic<\/a> zu nennen<\/p>\n

Jedes Paketformat wurde f\u00fcr einen speziellen Einsatzzweck entwickelt und setzt andere Schwerpunkte. RPM und DEB als eine der \u00e4ltesten Paketformate wurden als flexible Formate f\u00fcr den generellen Einsatz entwickelt. DEB hat dabei eine eigene Evolution durchgemacht, da Debian selbst als winzige Distribution mit nur einer Handvoll Pakete und sehr einfach gestricktem Paketformat gestartet ist, und dann wesentlich gr\u00f6\u00dfer wurde. Das DEB-Format wurde dabei leicht an die gr\u00f6\u00dferen Anforderungen angepasst. RPM kam von Beginn an f\u00fcr gr\u00f6\u00dfere Paketquellen zum Einsatz, hat sich aber ebenfalls ver\u00e4ndert.<\/p>\n

Warum wechselt jetzt nicht z.B. Debian zu RPM oder Fedora zu DEB? Die Gr\u00fcnde sind ziemlich pragmatisch: Es hat keinen Sinn und w\u00e4re kontraproduktiv. Der gesamte Workflow in Debian ist auf das DEB-Format ausgerichtet, alle Entwickler kommen damit klar, es funktioniert hervorragend und erf\u00fcllt alle Anspr\u00fcche. Gleiches gilt f\u00fcr RPM bei Fedora: Es hat schlicht keinen Sinn, zu wechseln. Der Nutzer h\u00e4tte nichts davon, und f\u00fcr die Entwickler w\u00e4re es sinnloser Aufwand.<\/p>\n

\n

Zur\u00fcck zur \u00dcbersicht<\/a><\/em><\/strong><\/span><\/p>\n

\n

Paketverwaltungsbestandteile<\/h2>\n

Die zwei o.g. Paketverwaltungssysteme APT (Advanced Packaging Tool) und RPM\u00a0 (RPM Package Manager) gliedern sich in folgende Teilprogramme auf, wobei jeder Bestandteil eine spezielle Funktion \u00fcbernimmt.<\/p>\n

dpkg-buildpackage<\/strong> ist ein Entwicklertool, es wird auf produktiven Systemen nicht verwendet und hat da eigentlich auch nichts zu suchen. Es verwendet v\u00f6llig andere Parameter als das Pakettool und der Paketmanager, es macht also Sinn, dieses separat zu haben.<\/p>\n

Das Pakettool (<\/strong>dpkg \/ rpm) verarbeitet lokale Pakete und abstrahiert die ganzen Details des Paketformates vom Paketmanager. Der Paketmanager muss nur noch das Pakettool aufrufen, um ein Paket zu installieren oder zu entfernen.<\/p>\n

Der Paketmanager<\/strong> (APT \/Zypper,Yum) hat den \u00dcberblick \u00fcber die gesamte auf dem System installierte Software, sowie \u00fcber verf\u00fcgbare Software und deren Quellen. Er ist au\u00dferdem in der Lage, Abh\u00e4ngigkeiten zwischen Paketen aufzul\u00f6sen und dem Pakettool genau zu sagen, welche Aktion wann aufgerufen werden muss, um das System in einem konsistenten Zustand zu halten und alle Pakete sinnvoll zu installieren\/zu entfernen.<\/p>\n

Diese Aktionen sind hoch spezialisiert und daher voneinander getrennt. Der Paketmanager braucht keine genaue Kenntnis vom Paketformat, ebenso wenig, wie das Pakettool wissen muss, was gerade im gesamten Archiv passiert. Mit all dem \u00fcberhaupt nichts zu tun hat das Paket-Entwicklerwerkzeug.<\/p>\n

Zugegeben, ein Paket ist komplex \u2013 allerdings ist diese Komplexit\u00e4t oft essenziell. Und nahezu alle Dateien sind einfache Textdateien, die sowohl von Menschen gut gelesen werden k\u00f6nnen, als auch von Maschinen verarbeitet werden k\u00f6nnen. Paketmanager und Pakettool k\u00f6nnen in einer Anwendung zusammengefasst werden ( Arch Linux ), was aber in Bezug auf Flexibilit\u00e4t und Fehlersuche suboptimal ist.<\/p>\n

\n

Zur\u00fcck zur \u00dcbersicht<\/a><\/em><\/strong><\/span><\/p>\n

\n

PackageKit<\/h2>\n

PackageKit ist eine dritte Schicht \u00fcber dem Pakettool und dem Paketmanager und stellt viele Aktionen der Paketverwaltung \u00fcber eine Schnittstelle systemweit und unabh\u00e4ngig von den Paketverwaltungsbestandteilen zur Verf\u00fcgung. \u00dcber diese Schnittstelle k\u00f6nnen Nutzer mit dem Paketmanagement einfach kommunizieren, wenn sie sich nicht mit der (n\u00fctzlichen) Komplexit\u00e4t des Systems oder der Syntax der verschiedenen Paketverwaltungssysteme auseinandersetzen wollen. Somit sind folgende Befehle f\u00fcr Systeme auf denen Packekit installiert allgemein g\u00fcltig:<\/p>\n