Paketverwaltungen: Warum ist alles so kompliziert?

(Dieser Artikel ist hauptsächlich, aber nicht ausschließlich, eine Antwort auf einen Artikel von [ENC]BladeXP’s Blog)

Allgemeines

Ich kann leider hier nicht alles ganz detailliert für Einsteiger erklären, da dann dieser Artikel mindestens doppelt so lang werden würde. Wenn ihr aber Fragen habt, könnt ihr die gerne in den Kommentaren stellen!

Ein kurzer Hinweis am Rande: Für viele ist das Paketformat und die Paketverwaltung 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ält, sowie die Software, welche dieses Format einliest und verwaltet. Zum Anderen existiert der Paketmanager, welcher für das Interpretieren der Paket-Metainformationen (Abhängigkeiten, Konflikte, etc.) und für diverse Hilfsaufgaben (z.B. Repositories, Updates) zuständig ist.

Ein Paketformat wäre z.B. RPM, die Paket-Verwaltung und das zugehörige Tool heißen ebenfalls RPM. Für RPM gibt es nun diverse Paketmanager, z.B. Yum oder Zypper. (Bei Debian wäre das Paketformat deb/dpkg, der Paketmanager Apt)

Paketformate

Schaut man sich das Treiben bei den diversen Distributionen in punkto Paketverwaltung an, so hat sich sicher jeder schon einmal gefragt, warum nicht einfach alle ein einheitliches Paketformat verwenden.

Die Antwort ist sehr einfach: Jedes Paketformat wurde für einen speziellen Einsatzzweck designed und setzt andere Schwerpunkte. RPM und DEB als vielleicht älteste Paketformate wurden als flexible Formate für 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ößer wurde. Das DEB-Format wurde dabei leicht an die größeren Anforderungen angepasst.

RPM kam seit Beginn an für größere Paketquellen zum Einsatz, hat sich aber ebenfalls verändert.

Warum wechselt jetzt nicht z.B. Debian zu RPM oder Fedora zu DEB? Die Gründe sind ziemlich pragmatisch: Es hat keinen Sinn und wäre kontraproduktiv. Der gesamte Workflow in Debian ist auf das DEB-Format ausgerichtet, alle Entwickler kommen damit klar, es funktioniert hervorragend und erfüllt alle Ansprüche. Gleiches gilt für RPM bei Fedora: Es hat schlicht keinen Sinn, zu wechseln. Der Nutzer hätte nichts davon, und für die Entwickler wäre es sinnloser Aufwand.

Wie häufig in der Linuxwelt ist Vielfalt auch hier von Vorteil. Und selbst wenn DEB und RPM von den Features her inzwischen ähnlich sind, würde ein Wechsel sich für niemanden lohnen.

Warum so viele Tools für die Paketverwaltung?

In Debian gibt es dpkg-buildpackage zum Bauen von Paketen, dpkg zum Installieren/Entfernen von lokalen Paketen und Apt zum Verwalten von Paketquellen. Warum diese Vielfalt? Die Gründe sind einfach:

  • dpkg-buildpackage ist ein Entwicklertool, es wird auf produktiven Systemen nicht verwendet und hat da eigentlich auch nichts zu suchen. Es verwendet völlig andere Parameter als das Pakettool und der Paketmanager, es macht also Sinn, dieses separat zu haben.
  • Das Pakettool (dpkg) 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.
  • Der Paketmanager hat den Überblick über die gesamte auf dem System installierte Software, sowie über verfügbare Software. Er ist außerdem in der Lage, Abhängigkeiten zwischen Paketen aufzulösen 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.

Diese nötigen Aktionen sind hochspezialisiert, und es macht Sinn, sie zu trennen. Der Paketmanager braucht keine genaue Kenntnis vom Paketformat, ebensowenig, wie das Pakettool wissen muss, was grade im gesamten Archiv so passiert. Mit all dem überhaupt nichts zu tun hat das Paket-Entwicklerwerkzeug.

Man kann, wie es Arch-Linux macht, durchaus Paketmanager und Pakettool in einer Anwendung unterbringen (ich würde aber wetten, dass das intern abstrahiert ist), das geht dann aber auf Kosten der Flexibilität. Einzelne Komponenten zu testen ist immer leichter, zudem kann man Apt theoretisch auch dazu bringen, RPM-Pakete zu verwalten (wurde bereits gemacht). Ebenfalls sind Systeme ohne Apt möglich, was z.B. eim Embedded-Bereich nützlich ist.

Pakete bauen

Pakete bauen ist nicht einfach, und es gibt zig Tools die in diese Aufgabe involviert sind. In Debian sind das die debhelper-Tools (dh_*), welche bestimmte Aufgaben beim Paketbau automatisieren. (z.B. das Installieren von Icons/Initscripts, das Einsetzen von Paketabhängigkeiten, präprozessieren von Python-Scripten, …)

Das ist sehr sinnvoll, da der Distributionsentwickler haarklein kontrollieren kann, wie das resultierende Binärpaket aussieht. Da Software sehr divers ist, und es eine riesige Menge an Möglichkeiten gibt, wie die Upstream-Software programmiert sein kann, ist diese Flexibilität auch nötig.

Insbesondere Debian-Paketen wird häufig nachgesagt, dass zu viele Dateien nötig sind, um sie zu erstellen. Das stimmt meiner Meinung nicht, gerade dieses Format ist eines der Qualitätsmerkmale von Debian.

Ich nehme hier das Beispiel von ENCBladeXP für das Amarok-Debian-Paket:

debian/amarok.lintian-overrides
debian/NEWS
debian/amarok-utils.install
debian/man
debian/man/amarok.1
debian/man/amarokcollectionscanner.1
debian/man/amarokmp3tunesharmonydaemon.1
debian/rules
debian/README.source
debian/copyright
debian/control
debian/amarok.install
debian/compat
debian/not-installed
debian/icons
debian/icons/amarok.xpm
debian/icons/amarok-16.xpm
debian/bug-presubj.disabled
debian/amarok.manpages
debian/changelog
debian/amarok-common.install
debian/watch
debian/bug-control
debian/patches
debian/patches/debian
debian/patches/debian/disable_qtscriptbindings_check_fix.diff
debian/patches/debian/mysql_no_openssl_fix.diff
debian/patches/debian/mysqle_amarok_local_errmsg_feature.diff
debian/patches/series
debian/amarok-common.dirs
debian/amarok-utils.manpages
debian/README.Debian
debian/amarok.bug-presubj
debian/source
debian/source/format
debian/amarok.menu

Also, was sind das alles für Dateien? Alles unter patches/* sind – wer hätte es gedacht – distributionsspezifische Modifikationen, oder Patches vom Originalautor, die für das Paketrelease zurückportiert wurden. Macht also Sinn, die Patches einzeln zu haben.

README.Debian enthält Informationen über Debian-spezifische Modifikationen am Paket, oder Informationen, die allgemein für Debian relevant sind. Das hilft neuen Paketmaintainern, sich in dem Paket zurecht zu finden und ist eine nützliche Referenz, um sich über die Software in Debian zu informieren.

Die Datei changelog enthält ein Log sämtlicher am Paket vorgenommenen Änderungen, nebst Datum und Priorität der Änderung (z.B. “hoch” bei einem Sicherheitsupdate, wodurch die Software besonders schnell gebaut und verfügbar gemacht wird). copyright enthält eine maschinenlesbare Version des Copyrights für die Software in Debian. Das schließt eine explizite Copyright-Info für jede Datei im Upstream-Quellcode ein.

Die rules Datei enthält alle Informationen, die zum Paketbau nötig sind, die control Datei sämtliche Paketbeschreibungen und Metainfos (wie Abhängigkeiten) für das Paket. compat legt den Kompatibiltätsgrad zu den debhelper-Werzeugen fest, die Dateien unter source/ spezifizieren den Typ des Quellcode-Archiv und legen erweiterte Einstellungen für den Bau des Quellcodepaketes fest.

Die Datei mit der Endung lintian-overrides überschreibt Warnungen/Fehler des Automatischen Debian-Paketprüfers, welcher die Konsistenz und Qualität der Debian-Pakete überprüft. Die Datei wird in diesem Fall entweder eine falschpositiv-Meldung überschreiben, oder aber für dieses Paket wurde eine Ausnahme von der Debian-Policy gemacht, welche den override rechtfertigen.

Die Dateien unter man/ sind speziell von Debian-Entwicklern geschriebene Manual-Pages, um der Regel, dass jede Binärdatei in Debian eine Manpage haben sollte gerecht zu werden. Sie werden über Direktiven in .manpages Dateien für das Lesen im Terminal kompiliert und installiert.

Dateien mit der Endung .install enthalten alle Informationen, welche Datei der Software wo hin installiert werden soll.

Alle Dateien sind also sinnvoll. Wer mehr wissen will, dem sei der Debian Maintainer Guide empfohlen. Würde man alle diese Informationen in eine Datei quetschen, hätte man eine riesige, unübersichtliche Datei, und könnte nicht die Vorteile verschiedener Dateiformate nutzen.

Zugegeben, ein Paket ist komplex – allerdings ist diese Komplexität oft essentiell. Und nahezu alle Dateien sind einfache Textdateien, die sowohl von Menschen gut gelesen werden können, als auch von Maschinen verarbeitet werden können. Durch die Modularität ist ein Debian-Paket zudem sehr flexibel. Die Implementierung von Multiarch für Jessie war nicht zuletzt deshalb vergleichsweise “schnell” möglich.

Arch-Linux hat als Rolling-Release-Distribution ganz andere Anforderungen als Debian. Und bei komplexeren Paketen bestimmt auch eine größere PKGBUILD Datei. Da ich mich mit Arch-Paketen aber selber nicht auskenne, kann ich dazu nicht viel sagen 😉 .

In Fedora existieren aber sogar mehrere MiB große Specfiles.

Viele Tools zur Steuerung des Paketsystems…

Da es für jede Aufgabe im Paketsystem ein darauf spezialisiertes Tool gibt und viele Aktionen verkettet werden müssen, um einen gewünschten Effekt zu erzielen, muss man wenn man über die Kommandozeile auf das Paketsystem zugreift natürlich die Anfrage an das richtige Tool stellen. So weiß Apt z.B. überhaupt nichts über den Inhalt von Paketen, also macht es keinen Sinn, Apt danach zu Fragen. Hingegen ist dpkg genau das richtige Werkzeug für diesen Job. Für komplexere Aktionen an der dpkg-Datenbank steht zudem das dpkg-query wekzeug bereit.

Für Leute die in punkto Paketmanagement neu sind, mag das unlogisch sein, vom Aufbau des Paketmanagements ergibt diese Aufteilung jedoch Sinn.

Gerade bei Apt hat man jedoch auch versucht, den Satz “Ein Tool für eine Aufgabe” zu realisieren, weshalb es z.B. apt-cache, apt-mark, apt-key und apt-config gibt. Viele Programme wurden dabei nachträglich als Erweiterungen geschrieben, und niemand hat Sinn darin gesehen, sie in einer Codebasis zu vereinigen.

Was ist PackageKit?

Wer sich inzwischen gefragt hat, wo eigentlich PackageKit geblieben ist: Hier! 🙂 PackageKit ist eine dritte Schicht über dem Pakettool und dem Paketmanager. Es macht viele Aktionen der Paketverwaltung über eie DBus-Schnittstelle systemweit verfügbar. Damit kann jede Anwendung – unabhängig davon, ob das System Apt, Yum, Zyper, Alpm, etc. verwendet – Anfragen an die Paketverwaltung stellen. PackageKit kümmert sich darum, dass “der Richtige” im Paketsystem die Abfrage bekommt, und leitet die Antwort dann an die anfragende Anwendung weiter. PackageKit macht noch einiges mehr, besagtes ist aber die Hauptaufgabe.

So führt ein

pkcon update

auf allen Systemen zu einer Aktualisierung des Paket-Zwischenspeichers, ein

pkcon upgrade

zu einer Aktualisierung des Systems, ein

pkcon search file /path/to/filename.txt

zum Auflisten eines Paketes, welches die besagte Datei enthält.

Über diese Schnittstelle können Nutzer mit dem Paketmanagement einfach kommunizieren, wenn sie sich nicht mit der (nützlichen) Komplexität des Systems abgeben wollen.

Komplexität

Das Paketmanagement einer Distribution ist mitunter unglaublich komplex. Das liegt aber nicht daran, dass die Programmierer das so gewollt haben, sondern viel mehr am komplexen Problem selber.

Alleine der Paketbauprozess muss mit ettlichen Buildsystemen für Software zurecht kommen, es müssen zig verschiedene Dateien an dir richtigen Orte installiert und registriert werden. Zudem muss auch noch auf distributionsspezifische Eigenheiten eingegangen werden. Damit muss der Buildprozess sehr flexibel sein, was ihn automatisch komplizierter machen kann. (unter Debian reicht aber inzwischen häufig ein Zweizeiler in der rules Datei, um die Software korrekt zu bauen – es wird also daran gearbeitet, viel der Komplexität zu verstecken und Dinge zu automatisieren).

Das Pakettool hingegen muss seine Datenbank extrem schnell verwalten können, und muss zu jeder Zeit sicherstellen, dass diese konsistent ist, und nicht beschädigt wird. (Was passiert z.B. bei einem Stromausfall während eines Upgrades? Dpkg hat da Möglichkeiten, selbst das zu retten)

Der Paketmanager muss die ganzen Paketpools verwalten, und Abhängigkeiten zwischen Paketen möglichst schnell auflösen. Dazu zählen nicht nur “Paket X braucht Paket Y”-Abhängigkeiten, sondern auch Konflikte eines Paketes mit einer Version eines anderen Paketes, oder vom Nutzer festgelegte Sperren eines Pakates (z.B. apt-pinning).

Fazit

Jeder Versuch, das Paketmanagement radikal zu vereinfachen wird auf Grund des Problems selber nicht funktionieren, oder nur unter Verlust vieler Funktionen und der “Robustheit” des Systems. Zudem ist jedes Paketmanagement quasi mit der Distribution “gewachsen”, es zu ersetzten würde also in jedem Fall erstmal zu mehr Bugs und Problemen führen. Um das zu tun, braucht man also schon einen triftigen Grund.

Was allerdings auch stimmt, ist dass der Zugang zum Paketmanagement unnötig kompliziert ist, vor allem für simplere Aufgaben. Auch noch so komplexe Dinge kann man hinter einer schönen GUI odert einem cleveren CLI-Tool verstecken. An dieser Stelle kann ich jedem das PackageKit tool pkcon empfehlen, welches alle allgemeinen Aktionen der Paketdatenbank abdecken sollte.

Dieser Artikel reißt eigentlich das Thema Paketmanagement nur kurz (und leider doch relativ unstrukturiert 😛 ) an, wer Interesse daran hat, dem sei zum Paketebau der Debian Maintainer Guide empfohlen. Für alles andere fehlt manchmal leider ein wenig Dokumentation, Manpages helfen aber bei den einzelnen Tools sehr. Auch interessant dürfte Kapitel 2 des Debian Reference Guides oder die Wiki-Seiten zum Debian-Paketmanagement sein. Wen die Entwicklung der Tools interessiert, der kann ja mal auf #debian-apt (OFTC) oder #PackageKit (Freenode) vorbei schauen 😉

13 thoughts on “Paketverwaltungen: Warum ist alles so kompliziert?

  1. RPM ist LSB-Standard. Alles andere ist NIH-Blödsinn.
    SUSE hat auch mal das Paketformat hin zu RPM gewechselt und es ging. Maemo vor einigen Jahren auch, als es zu MeeGo wurde und ging auch.

    OBS kann beide Paketformate erstellen. Wenn man migriert, kann man das auch schrittweise tun, indem man zuerst OBS deployt und OBS beide Paketformat ausgeben lässt.

    1. Sorry, aber das ist Unsinn… Zuerst einmal existierten viele Paketformate eh schon, bevor die LSB erstellt wurde. Zum zweiten schreibt die LSB eben gerade nicht RPM als Paketformat fest, sondern fordert vielmehr, dass binäre software zumindest theoretisch als RPM installiert werden kann. Das funktioniert unter nicht-RPM-basierten Systemen zwar nicht sehr gut, geht aber zumindest bei simplem Paketen.

      Nutzt man den OBS, so muss man für RPM *und* für z.B. DEB jeweils einzeln Quellpakete erstellen, und vor allem diese zueinander synchron halten, was ein enormer Aufwand ist, auch elleine deshalb, weil RPM-Paketnamen case-sensitive sind, und DEB-Pakete nicht.

      Als Maemo zu MeeGo wurde, wurden im Grunde alle alten Pakete weggeworfen und nur die Patches in die existierenden MeeGo-Pakete integriert, eine echte migration war das eher nicht. Zudem ist MeeGo als embedded-System mit anderen Anforderungen konzipiert und enthält nur eine begrenzte Anzahl an Basispaketen, welche einen Bruchteil der Pakete in Fedora oder Debian darstellen.

      Zu Tizen kann ich nichts sagen, nur dass der Codebaum das letzte mal als ich draufgeschaut habe a) nur aus ca. 80 Paketen bestand und b) Ein extremes Chaos an Debian-Quellpaketen und RPM-Specfiles vorhanden war (und ich gar nicht wusste, was sie jetzt eigentlich verwenden, da sowohl ein paar Pakete mit Debian synchronisiert wurden, als auch Specfiles von Fedora/OpenSUSE geliehen wurden.)

  2. PS: Tizen 1.0 basierte aufgrund der LiMo-Wurzeln auf deb und wechselte mit 2.0 auf RPM.
    Alles also machbar und offensichtlich gar nicht so tragisch.

  3. Leicht Verständlich und Trozdem Komplex 🙂 Super! Sogar ich habs verstanden ,DANKE!!

    1. In der Tat 🙂 Sobald ich Feedback von der Ubuntu-crew habe, wird es dazu einen kleinen rant-Artikel geben (oder auch nicht ^^). Ubuntu’s Paketformat ist nämlich exakt das gleiche, was mein Listaller projekt jetzt schon bietet, der einzige Unterschied ist, dass Ubuntus Pakete nicht distributionsübergreifend sein werden. (zumindest nicht ohne viel Aufwand)

  4. Es gibt schon eine sehr einfache Möglichkeit, der Paketverwaltung. Nämlich gar keine. Slackware ist dafür ein Parade Beispiel. Das erstellen einer .txz ist sehr einfach, das erstellte Paket ist sehr übersichtlich. Mit Slackpkg bekommt man eine einfache Paketverwaltung dazu, was für normales Anwenden völlig ausreicht, aber genau sogut auch nicht nötig ist. Darum favorisiere ich Slackware, weit über Debian/Ubuntu, Fedora, openSuSE usw.

    Nur ist das heute nicht mehr behindert… ich meine … modern genug :-/

    Es ist viel cooler, sein gesamtes System, unnötig zu verkomplizieren und quasi, einfach neuere Software unter älterem System, unmöglich zu machen, wegen tonen von Abhängigkeiten. Dafür gibt es dann Backports, PPAs und sonst was für Quark, das sofort wie ein Weib zickt, wenn sie nicht das bekommt, was SIE will. Nee nee, alternativen gibt es doch, nur wird man die beim Mainstream nicht finden. Und die werden sich nicht wenden, sondern so schlecht bleiben wie sie sind.

    Man muss sich eben entscheiden, was man will. Will man eine “Wir wissen es besser als Benutzer selbst, was gut für ihn ist”-Distribution, wie Ubuntu. Oder eher die, “Mach doch was DU denkst”-Distribution wie Slackware. Klar, der Aufwand ist unter Slackware höher. Aber man genießt deutlich mehr Freiheiten, als beim Mainstream.

  5. Yeah . I agree they interviewed the wrong sites.I was tynirg to be nice.I seriously don’t think RHEL would show up on sites with more than say 5 machines. It’s just too hard to manage at scale. All the sites I talk to use Debian.

Leave a Reply to Kurt Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.