RPM-Pakete von und für Python

Wer einmal mehr als oberflächliche Bekanntschaft mit einer Skriptsprache unter Linux gemacht hat, kennt das Problem: Jede kocht, was das Management von Modulen und Bibliotheken betrifft, ihr eigenes Süppchen. Da haben die Distributoren viel Mühe aufgewendet, um mit Dpkg/Apt und RPM alle Dateien in Pakete zu packen, die sich einfach installieren und wieder entfernen lassen, doch die Programmiersprachen machen nicht mit. Perl hat schon seit Urzeiten sein CPAN-Interface, Ruby seine Gems, PHP will statt Äpfel lieber Birnen und setzt auf Pear. Die Lua-Gemeinde ist sich noch uneinig und bietet neben Luarocks noch Luadist, selbst Node.js, der neueste Hype der Webwelt, hat mit NPM ein eigenes Paketsystem zu bieten.

Wenn eine Linux-Distribution eine der Sprachen ausliefert, sind oft auch wichtige Bibliotheken im distributionseigenen Format vorhanden, doch früher oder später braucht man ein Modul, das im Repository fehlt. Dies lässt sich zwar leicht installieren, doch dann ist die schöne Konsequenz des Paketmanagements dahin. Bei einem Upgrade oder einer Migration muss man sich mindestens eine Liste der installierten Skript-Module machen und sie dann erneut von Hand installieren.

Eier legen

In der Python-Community sind Erweiterungsmodule auch als Eggs [1] bekannt, die früher über das Tool »easy_install« [2] verwaltet wurden, wenn man das so nennen will, denn außer der Installation beherrscht es wenige Funktionen. Zum Beispiel kann es nicht die installierten Pakete auflisten oder wieder entfernen. Mittlerweile wurde es von »pip« [3] abgelöst, das in dieser Beziehung mehr zu bieten hat. Beide Tools können jedoch Abhängigkeiten auflösen und die geforderten Pakete direkt aus dem Netz laden und anschließend installieren.

Zentrale Anlaufstelle für alle Bedürfnisse rund um Python-Module ist der Python Package Index (PyPI, [4]), informell auch Cheeseshop genannt – gerne benennen Python-Programmierer ihre Werkzeuge nach Gegenständen aus der Welt von Monty Python, den Namenspatronen der Sprache [5]. Wenn Sie zum Beispiel die Bibliothek Cloth installieren möchten, die virtuelle Maschinen der Amazon-Cloud EC2 fernsteuern kann, verwenden Sie dazu den folgenden Befehl:

pip install cloth

Sie müssen ihn allerdings mit Root-Rechten ausführen, denn das kleine Programm will in die Python-Modulverzeichnisse schreiben, die typischerweise in »/usr/lib/pythonVersion« , »/usr/lib64/pythonVersion« und so weiter liegen. Im konkreten Fall installiert »pip« zusätzlich noch die benötigten Python-Module »fabric« und »ssh« . Bei Fedora Linux heißt Pip, wenn man es über den Paketmanager installiert, übrigens »python-pip« , das zugehörige Kommando aber »pip-python« . Eine Liste der installierten "Eier" zeigt »pip freeze« , das Upgrade eines Pakets spielt man per »pip install -U Paketname« ein. Entfernen lässt sich ein Modul mit »pip uninstall Paketname« .

Spätestens jetzt ist aber der Punkt erreicht, an dem es unübersichtlich wird: Manche der Eggs, die sich etwa auf dem Fedora-System in »/usr/lib/python2.7/site-packages/« befinden, wurden mit dem RPM-Paketmanager des Systems installiert; die anderen mit Pip, aber von denen weiß RPM nichts, wie ein Aufruf von »rpm -qf« zeigt (Listing 1).

Das Problem lässt sich dadurch lösen, dass man von den benötigten Python-Modulen eigene RPM-Pakete baut und diese auf dem System installiert, statt direkt Pip zu verwenden. Das ist etwas aufwendiger, doch wenn man eine größere Zahl von Produktionssystemen betreut, auf die man kontrolliert und regelmäßig Python-Module installieren möchte, lohnt sich der Aufwand.

Phasenweise

Im Prinzip unterscheiden sich RPM-Pakete mit Python-Modulen nur wenig von solchen mit Binärprogrammen: Das sogenannte Spec-File enthält die Metadaten für das Paket und legt fest, welche Dateien enthalten sind, und wo sie auf dem Zielsystem landen sollen. Anders sind nur die Phasen der Konfiguration und der Übersetzung. Wo Binärprogramme heute meistens Autoconf verwenden, um den Quellcodebaum vorzubereiten, gibt es bei Python dafür andere Mittel. Die bei C-Programmen obligatorische Compile-Phase fällt bei Python-Modulen oft weg – allerdings gibt es auch Module, die kleine C-Bibliotheken compilen.

Zu Beginn sind die gleichen Voraussetzungen zu erfüllen, wie sie beim Bauen von RPM-Paketen immer nötig sind. Als Administrator Root zu arbeiten, ist weder ratsam noch notwendig. Also legen Sie sich als gewöhnlicher Benutzer im Home-Verzeichnis ein Verzeichnis »rpmbuild« mit den Unterverzeichnissen »BUILD« , »RPMS« , »SOURCES« , »SPECS« und »SRPMS« an. Das lässt sich mit einem einzigen Befehl erledigen:

mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}

Typischerweise verwenden die RPM-Tools standardmäßig diese Einstellungen. Tun sie das nicht, hinterlegen Sie das entsprechende Makro »%_topdir« in der Einstellungsdatei »~/.rpmmacros« :

echo '%_topdir %(echo $HOME)/rpmbuild' >> ~/.rpmmacros

Makros sind mit einem Prozentzeichen gekennzeichnet und können auch Befehle enthalten.

Die Programme, die nötig sind, um RPMs zu bauen, stecken im Paket »rpm-build« . Weitere wichtige Makros und andere Einstellungen finden sich in »redhat-rpm-config« . Auch die Python-Entwicklungspakete sollten Sie bei der Gelegenheit gleich installieren:

yum install rpm-build redhat-rpm-config python-devel python-setuptools

Damit sind alle Voraussetzungen erfüllt, und Sie können daran gehen, die Spec-Datei für das Paket zu schreiben.