Vorsprech

Heute werde ich mal einigen Entwicklern von Paketverwaltungen auf die Füße treten, ich verspreche aber das es nicht sehr weh tut und ihr das bitte nicht persönlich nehmen möchtet. Mir geht es darum mal die Perspektive eine Anwenders zu zeigen, vor allem aber wie meiner Meinung nach eine ideale Paketverwaltung zu funktionieren hat.

Aktuelle Situation

Aktuell haben wir bei allen Distributionen mehr oder weniger unterschiedliche Tools zum erstellen oder installieren von Paketen. Je nach ursprünglicher Philosophie dieser Distribution, und natürlich auch abhängig vom Alter eben dieser, spürt man gerade als Anwender/Entwickler das diese Stück für Stück gewachsen sind.

Diese Anpassungen wurden erforderlich da z.B. Anwender neue Features haben wollten, oder aber man versucht hat ein Problem zu lösen. Die relativ neuen, und meiner Meinung nach moderneren Paketverwaltungen haben hier den Vorteil noch relativ aufgeräumt zu sein. Leider wird bei den vielen Anpassungen aber zu gerne vergessen auch mal ausmisten. Doch dazu später mehr.

Wenn wir uns mal 3 Distributionen aussuchen (Derivate davon ignoriere ich jetzt einfach mal) mit welchen ich mit etwas auskenne:

  • Debian: apt-get und dpkg
  • Fedora: yum und rpm
  • Arch Linux: pacman
Was fällt und sofort auf? Die alten Distributionen haben ein Tool für das eigentliche Paketformat und dann noch zusätzlich eines welches primär zum Suchen, Installieren, Entfernen und Aktualisieren von Paketen genommen wird.

Bei Debian gibt es z.b. dpkg schon seit Version 1.1 (Codename buzz von 1996), apt kam jedoch erst 1998 mit Version 2.1 (Codename slink) dazu. Ähnlich verhält es sich bei Red Hat oder SuSE, es gab immer zuerst ein relativ einfaches Pakettool samt Buildsystem und etwas später dann ein Tool welches sich damit beschäftigt dies auch für den Anwender in brauchbare / einfache Form zu bringen.

Grundlegend hat man also 3 verschiedene Systeme mit denen man Arbeiten muss:

  • Buildsystem vom Backend (z.B. dpkg-buildpackage)
  • Pakettool (z.B. dpkg)
  • Paketverwaltung (z.B. apt-get)

Euch ist bestimmt schon aufgefallen das ich gerade nichts mehr zu Arch Linux bzw. pacman sage? Nun, pacman hat keine 3 Systeme/Teile sondern nur noch 2:
  • Buildsystem (makepkg)
  • Paketverwaltung (pacman)
Das Pakettool (auch Backend genannt) und die Paketverwaltung (auch Frontend genannt) wurden also in einem Tool vereint.

Probleme der aktuellen Situation

Tools, Tools, Tools, …

Ein Problem der aktuellen Situation ist das es für eine Aufgabe, z.B. dem bauen eines neuen Paketes zu viele verschiedene Tools gibt. Wir nehmen als Referenz pacman, und sehen uns mal an was uns diese Paketverwaltung inkl. Buildsystem installiert: 

[stefan@arch ~]$ pacman -Ql pacman | grep bin
pacman /usr/bin/
pacman /usr/bin/cleanupdelta
pacman /usr/bin/makepkg
pacman /usr/bin/pacman
pacman /usr/bin/pacman-db-upgrade
pacman /usr/bin/pacman-key
pacman /usr/bin/pacman-optimize
pacman /usr/bin/pacsort
pacman /usr/bin/pactree
pacman /usr/bin/pkgdelta
pacman /usr/bin/rankmirrors
pacman /usr/bin/repo-add
pacman /usr/bin/repo-elephant
pacman /usr/bin/repo-remove
pacman /usr/bin/testdb
pacman /usr/bin/testpkg
pacman /usr/bin/vercmp
Das gleiche nun auf einem Debian System: 
stefan@debian:~# dpkg -L apt apt-utils dpkg dpkg-dev | grep usr/bin | sort
/usr/bin
/usr/bin/apt-cache
/usr/bin/apt-cdrom
/usr/bin/apt-config
/usr/bin/apt-extracttemplates
/usr/bin/apt-ftparchive
/usr/bin/apt-get
/usr/bin/apt-key
/usr/bin/apt-mark
/usr/bin/apt-sortpkgs
/usr/bin/dpkg
/usr/bin/dpkg-architecture
/usr/bin/dpkg-buildpackage
/usr/bin/dpkg-checkbuilddeps
/usr/bin/dpkg-deb
/usr/bin/dpkg-distaddfile
/usr/bin/dpkg-divert
/usr/bin/dpkg-genchanges
/usr/bin/dpkg-gencontrol
/usr/bin/dpkg-gensymbols
/usr/bin/dpkg-name
/usr/bin/dpkg-parsechangelog
/usr/bin/dpkg-query
/usr/bin/dpkg-scanpackages
/usr/bin/dpkg-scansources
/usr/bin/dpkg-shlibdeps
/usr/bin/dpkg-source
/usr/bin/dpkg-split
/usr/bin/dpkg-statoverride
/usr/bin/dpkg-trigger
/usr/bin/dpkg-vendor
/usr/bin/update-alternatives
Das ganze mal in Zahlen:
  • pacman: 16 Tools
  • apt/dpkg: 31 Tools
Wobei natürlich Zahlen allein keine Aussagekraft haben, man sieht aber sehr deutlich wie stark die Paketverwaltung bei Debian gewachsen ist und immer wieder neue Tools geschaffen wurden anstatt diese in vorhandene Tools zu integrieren.

Die Liste von Debian ist übrigens noch lange nicht vollständig, es fehlen noch weitere Tools wie z.B. dch. Da sollte man wirklich mal drüber nachdenken, oder?

Buildsystem, oder der Versuch es kompliziert zu machen.

Eine weitere Freizeitbeschäftigung vieler Entwickler scheint es zu sein ein Buildsystem über möglichst viele Dateien zu verteilen. Sehen wir uns hierzu mal das Paket von Amarok und Arch sowie Debian an: 

[stefan@pc2007 amarok]$ find debian/
debian/
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
Und jetzt das ganze bei Arch Linux: 
[stefan@pc2007 amarok]$ find /var/abs/extra/amarok/
/var/abs/extra/amarok/
/var/abs/extra/amarok/amarok.install
/var/abs/extra/amarok/amarok-2.5.0-ffmpeg-fixes.patch
/var/abs/extra/amarok/contextviewfix.patch
/var/abs/extra/amarok/toolbarfix.patch
/var/abs/extra/amarok/PKGBUILD
Beide Distributionen liefen für den Anwender ein funktionierendes Amarok aus, nicht alle Dateien die hier aufgelistet sind gehören zum Buildsystem sondern sind Paketspezifisch.

Der Buildprozess ist bei Debian auf viele kleinere Dateien verteilt, z.B. debian/control oder debian/rules. Arch verwendet für den kompletten Bau des Paketes ausschließlich die Datei mit dem Namen PKGBUILD, der Rest sind auch hier Distributionsspezifische Anpassungen oder fixes für neuere Versionen einiger Libraries.

Viele der Dateien die Debian für den Bau von Paketen braucht enthalten nur relativ wenig Informationen, die debian/compat z.B. nur die Zahl "7" bei oben genanntem Paket.

Es ist also immer wieder erforderlich zwischen verschiedenen Dateien bei Änderungen umzuschalten, und andere müssen z.B. beim Updaten auf eine neue Version zwingend geändert werden.

Das ganze Drama geht noch wesentlich weiter, es ist nicht nur so das man viele verschiedene Dateien für den Bau eines Paketes hat sondern zusätzlich hat man auch noch viele verschiedene Tools und Helfer welche sich um die Auswertung oder Aktualisierung eben dieser Dateien kümmern. Die Datei debian/changelog wird z.B. normalerweise mit dem Tool dch gepflegt.

Das Problem an der Sache ist das neue Leute welche Pakete bauen wollen sich von derart Komplexen Systemen abschrecken lassen, noch schlimmer aber ist es wenn durch unwissen Pakete entstehen welche dann Probleme auf dem System bei der Installation erzeugen. Das ganze verstärkt sich dann noch zusätzlich durch die teilweise massive Verwendung von PPAs bei z.B. Ubuntu welches effektiv nur dafür sorgt das die Supporter bei ubuntuusers.de zusätzliche Arbeit bekommen.

Anwenderprobleme

Mit dem Buildsystem hat ein normaler Anwender recht wenig zu tun, dafür umso mehr mit den ganzen anderen Tools. Wir machen jetzt mal verschiedene Sachen mit apt/dpkg und pacman um zu zeigen wie groß hier die Unterschiede sind.

Ich habe mir dafür folgende Aktionen ausgesucht:

  1. Aktualisierung der Paketquellen
  2. Aktualisierung des Systems
  3. Entfernen eines Paketes
  4. Auflisten der Dateien eines Paketes
  5. Anzeige zu welchem Paket eine Datei gehört
Das ganze sind also wirklich die absoluten Grundlagen mit welchen jeder normale Anwender arbeiten muss.

Aktualisieren der Paketquellen

Das aktualisieren der Paketquellen ist eine Aufgabe die viele von uns täglich erledigen. Ziel ist es zu prüfen ob es neuere Paketquellen auf den Servern der Distributoren gibt.

Bei Debian funktioniert dies so: 

sudo apt-get update
Also wirklich ganz einfach gemacht, perfekt.

Auf einem Arch Linux sieht dies so aus: 

sudo pacman -Sy
Sieht nicht ganz so einfach aus, tut aber genau das gleiche.

Aktualisieren des Systems

Das aktualisieren des Systems ist auch so eine Aufgabe die man typischerweise täglich oder zumindest wöchentlich erledigt. Ziel ist es dafür zu sorgen das z.B. Sicherheitslücken geschlossen oder neue Versionen ohne bestimmte Probleme eingespielt werden.

Bei Debian funktioniert dies so: 

sudo apt-get upgrade
sudo apt-get dist-upgrade
Richtig, es gibt 2 verschiedene Befehle dafür. Wer Debian oder Ubuntu kennt weiß das ein dist-upgrade dafür gedacht ist von z.B. Debian 3.0 auf 4.0 zu aktualisieren.

Bei Arch Linux sieht dies so aus: 

sudo pacman -Su
Das ganze ist also nur ein Befehl, zusätzlich kann man das aktualisieren der Paketquellen und das aktualisieren von Paketen in einem Schritt machen: 
sudo pacman -Syu
Eine Aktualisierung von einem Arch Release auf ein neues gibt es nicht, Hintergrund ist das Arch genauso wie Gentoo eine Rolling Release Distribution ist.

Entfernen eines Paketes

Das entfernen von Paketen ist etwas das man, leider, eher selten macht da einen zu viele installierte Pakete in der Regel nicht stören.

Bei Debian funktioniert dies so: 

sudo apt-get remove paketname
Das ganze ist also auch hier sehr einfach umgesetzt, zusätzlich gibt es statt dem remove auch ein purge welches dafür sorgt das Konfigurationsdateien von einem Paket bei der Deinstallation auch gelöscht werden sollen.

Bei Arch Linux sieht dies so aus: 

sudo pacman -R paketname
Also auch einfach, nur das man sich ein paar Buchstaben gespart hat.

Auflisten der Dateien eines Paketes

Das ist jetzt eine weniger übliche Option, ich schau damit aber immer gerne nach welche Binaries mir ein installiertes Paket im System hinterlegt hat.

Fangen wir wieder mit Debian an: 

dpkg -L paketname
Fällt euch was auf? Richtig, ihr dürft das nicht mit apt machen sondern müsst wirklich direkt das Backend dpkg bedienen um an diese Information zu kommen.

Zurück zu Arch Linux: 

pacman -Ql paketname
Hier wird nach wie vor das gleiche Tool verwendet.

Anzeige zu welchem Paket eine Datei gehört

Ab und an möchte man wissen zu welchem Paket den eine Datei gehört die man im System gefunden hat, eine weniger übliche Tätigkeit.

Unter Debian würden wir das ganze wohl so erledigen: 

dpkg-query -S /der/datei/name
Schon wieder ein neues Tool? Ernsthaft? Das ganze funktioniert übrigens nicht für jede Datei in z.B. /usr/bin da einige davon von update-alternatives verwaltet werden und diese somit nicht von der Paketverwaltung erfasst werden. Übrigens ist mir bekannt das es auch mit dpkg -S gehen würde, welches aber wohl auch nur dpkg-query aufruft für die eigentliche Arbeit ;-)

Jetzt zum letzten mal zurück zu pacman bzw. Arch Linux: 

pacman -Qo /der/datei/name
Auch hier macht wieder unsere Paketverwaltung die Arbeit, nicht ein weiteres Tool.

Lösungsvorschläge

Wie könnte man das ganze für Anwender und Entwickler wieder etwas vereinfachen bzw. ausmisten? Hierzu habe ich euch mal ein paar Regeln aufgestellt, ihr dürft euch aber natürlich selbst aussuchen ob ihr diese Vorschläge/Regeln annehmen wollt:

Weniger ist mehr
Eine sehr einfache Regel, reduziere die Anzahl der Tools auf das nötigste. Weniger Tools bedeutet das ein Anwender auch weniger Suchen muss bis er das richtige Tool hat. Auch die benötigen Dateien für ein neues Paket sollten so wenig wie möglich sein. Ein Projekt welches gezeigt hat das dies möglich ist war z.B. git, dort gab es früher auch für viele Sachen eigene Binaries welche heute in ein einziges zentrales Tool überführt wurden.
KISS - Keep It Simple, Supid
Halte deine Tools so einfach wie möglich, für etwas das ein Entwickler nur alle 5 Jahre benötigt braucht man kein Tool, das kann dieser Entwickler auch schnell per Hand/Script machen. Schreibt sowas in die FAQ.
Zeit für Veränderungen
Wir haben 2012, wir können es uns also erlauben Sachen die wir schon viele Jahre haben, und mit welchen wir sehr unzufrieden sind, einfach zu entfernen.
Fasse dich kurz
Genau das was ich in diesem Artikel falsch gemacht habe machen auch viele Entwickler falsch: Zu viele Policies, Anleitungen, Guidlines mit noch dazu viel zu viel Text. Wenn man einem Entwickler/Anwender ein Verfahren erst auf mehreren DIN A4 Seiten erklären muss damit dieser den Prozess dahinter verstehen kann läuft meistens was falsch - am System ;-)
Geschwindigkeit
Deine Paketverwaltung sollte schnell sein, das gilt auch für Sachen die aus dem Internet geladen werden. Jeder Online Zugriff kostet Zeit, und sollte daher so effektiv und selten wie möglich erfolgen. Auch das einlesen der Paketdatenbank und sonstiger Metadaten kostet Zeit und sollte so selten wie möglich erfolgen.
Buildsysteme
Das Buildsystem der Paketverwaltung sollte dem Entwickler dabei helfen ein Paket zu erstellen, heute läuft es oft andersrum: Der Entwickler hilft dem Paketsystem ein Paket zu erstellen. Ein Buildsystem ist ein Dienstleister, dieser sollte nur die relevante Metadaten (Paketname, Version, Quelle, Lizenz, ..) und die Informationen aus deiner INSTALL Datei bekommen und damit ein Paket bauen. Je mehr man von der INSTALL Datei abweicht desto schlechter ist das Buildsystem. Der klassische Dreisatz (./configure, make, make install) sollte als Referenz dienen!
Rewrite
Jeder Softwareentwickler weiß das man irgendwann an einer Stelle ist an der jede weitere Neuerung einfach keinen Spaß mehr machen. Gleichzeitig ist auch irgendwann der Zeitpunkt erreicht an dem man ausmisten sollte. Nutzt diese Gelegenheit!
Komplexität
Ich habe oben schon was bzgl. KISS geschrieben, aber hier nochmal: Lasst eure Tools einfach, Dinge wie debconf, defoma oder alternatives machen das ganze System komplexer, bringen aber 90% der Anwender kaum eines großen Mehrwert.

Mal eine kleine Vorstellung

Hier mal eine kleine Vorstellung wie ich mir das als Anwender vorstellen könnte, vielleicht kommt ja jemand auf den Geschmack: 

apt install paketname
apt remove [--purge] paketname
apt update
apt upgrade
apt buildpackage
apt sources paketname
apt changes paketname
apt search suchbegriff
apt owns dateiname
apt show [--remote|--local] paketname
Fällt euch was auf? Ihr habt schon verdammt viel davon umgesetzt, d.h. ihr seid auf einem guten Weg. Wenn man jetzt noch Paketformate wie deb/rpm als Plugin implementieren könnte hätten wir zipper, apt-get, aptitude, yum ersetzt.

Fazit

Die aktuelle Situation der alten Paketverwaltungen ist für langjährige Nutzer in Ordnung, wer von ganz unten anfängt wird sich aber öfters mal an den Kopf fassen, da er nicht verstehen wird warum wir eine Paketverwaltung an so vielen unterschiedlichen stellen in derart viele Tools aufteilen müssen.

Der ganze Artikel verwendet übrigens pacman nur als Alternative zu apt-get um zu zeigen das es auch anders geht, es soll nicht gezeigt werden das pacman das bessere Tool wäre, was es praktisch gesehen auch einfach nicht ist. Auch Arch Linux soll hier nicht als die ultimative Distribution verwendet werden, Debian oder Ubuntu sind nach wie vor gute Distributionen die ich auch gerne z.B. auf einem Server einsetze.

Der Artikel soll zeigen welche Probleme wohl ein neuer Anwender/Entwickler mit den heute oft verwendeten Paketverwaltungen haben wird. Denn ein neuer Entwickler schreibt ein Paket für eure Distribution nicht als Hauptaufgabe sondern nur weil er es dem Anwender leichter machen möchte. Es ist nicht der Sinn das sich ein Entwickler beim erstellen eines Paketes für eure Distribution erst durch ca. 200 Manpages, Guidlines und Policies lesen muss um an eurem Projekt mithelfen zu können. Je niedriger die Einstiegshürde desto mehr Leute sind auch bereit zu helfen und ein Projekt voran zu bringen.

Ich selbst verwende Debian/Ubuntu schon viele Jahre, habe aber bewusst aufgezeigt welche Probleme wohl ein Einsteiger haben dürfte: Er darf permanent raten und fragen welches Tool den für seine Aufgabe welche er erledigen möchte nun das richtige sei. Aber auch Administratoren welche oft zwischen 2 oder mehr verschiedenen Systemen wechseln müssen immer wieder grübeln was den jetzt für das jeweilige Frontend/Backend der richtige Befehl wäre.

Vielleicht sollten sich die großen Distributionen, wie Debian, Ubuntu oder Fedora mal an die Nase fassen und den ganzen gewachsenen Wildwuchs etwas ausmisten. Vielleicht ergibt sich bei dieser Gelegenheit auch die Möglichkeit das gemeinsam an einem neuen Werkzeug gearbeitet wird, Administratoren welche häufig zwischen SLES/RHEL und Debian wechseln werden dies zu schätzen wissen.

Fazit 2.0

Ich denke dieser Artikel wird bei einigen Leuten die Alarmglocken erklingen lassen, kein Grund gleich auf Gefechtsstation zu gehen: Keep Cool.

Bei diesem Artikel geht es übrigens auch nicht darum ob jemand Arch, Debian, Ubuntu oder Fedora verwendet, ich selbst sehe das als allgemeines Problem und glaube das wir dort langfristig etwas machen sollten.

Es genügt wenn ihr euch mal Gedanken über das Thema macht, vielleicht war die eine oder andere Anregung dabei welche ihr auch umsetzen möchtet. Kritik zu diesem Beitrag ist Ausdrücklich erwünscht und kann mir per Mail auch gerne persönlich Mitgeteilt werden: paketdings@stefan-betz.net.

Es gibt auch weniger hilfreiche Kritik, Beispiele:

  • Das war schon immer so!
  • Machs doch selber wenn es dir nicht passt, ist doch OpenSource!
  • Wenn wir das jetzt aber ändern dann... $ARGUMENT!
Vielleicht möchte aber auch jemand selbst, so wie ich, einen Artikel über seine Gedanken zum Thema Paketverwaltung veröffentlichen und zur Diskussion stellen.