Wie versprochen will ich heute nach dem Arbeitsmaterial und der Bauanleitung vorstellen womit mein Werkzeugkoffer für das Bauen von Paketen bestückt ist. Auch ein paar Werkzeuge die ich nicht nutze, aber bestimmt für den ein oder anderen eine Alternative oder Ergänzung darstellen möchte ich kurz erwähnen.
Das Basiswerkzeug rpmbuild hat wohl jeder bereits einmal gesehen, der sich mit dem Thema befassen durfte. Unser Arbeitsmaterial Quelltext und Patches bereitgelegt, angewandt auf die Bauanleitung und es entstehen Schritt für Schritt oder auch in einem Rutsch sowohl Binärpakete als auch Sourcepaket. Letzteres kann alternativ auch als Ausgangspunkt dienen um ein Paket einfach für eine andere Zielplattform zu bauen. Und warum erwähne ich die Möglichkeit des schrittweisen Bauens? Einfach weil es mir so einfacher fällt das Spec-File zu entwickeln. Immer schön eine Sektion schreiben, testen, aus- oder verbessern und zur nächsten übergehen.
So ein bisschen was von Schweizer Armeemesser haben die rpmdevtools. Intial nutze ich hier rpmdev-setuptree um mir eine Buildumgebung aufzubauen. Die Templates von rpmdev-newspec und rpmdev-newinit stellen meist die Ausgangsbasis für die weitere Arbeit dar. Wenns mal wieder schnell gehen muss wird mit rpmdev-bumpspec die Version erhöht und ein Changelog-Eintrag erstellt bevor die neue Version gebaut wird. Bei komplizierter Nummerierung hilft rpmdev-vercmp und rpmdev-rmdevelrpms und rpmdev-wipetree unterstützen beim Hauskeeping. Die beiden letzten sind aber auch der Grund warum nur auf einer virtuellen Maschine paketiere. Selten genutzt werden die anderen Werkzeuge in dieser Sammlung, können aber auch sehr hilfreich sein.
Wenn ich rpmbuild als Schraubenschlüssel bezeichnet hätte dann wäre mock der Koffersatz mit allen Schraubenschlüsseln für jeden Schraubentyp. mock nimmt die gleiche Ausgangsbasis wie rpmbuild baut aber dann in einer chroot-Umgebungen Pakete für beliebige Architekturen und Distributionen. Aber nicht nur das, wenn ein Projekt neben dem Quelltext auch ein Spec-File in einem Git-Repository liegen kann, kann man mock die ganze Arbeit erledigen lassen. Es clont das Repository, baut ein Archiv und dann die Pakete. Wer dann auch gleich noch mehr auf einmal erledigt haben will nutz mockchain und lässt gleich mehrere Pakete bauen.
Die Wasserwaage zur Qualitätskontrolle stellt dann rpmlint dar. Dieses sollte gegen das Specfile, die nicht-installierten und installierten Pakete ausgeführt werden. Hierbei werden neben viele, viele formale Fehlern auch viele potentielle Probleme aufgezeigt. Einen Teil davon kann man sicher ignorieren, rpmlint aber komplett still zu bekommen sorgt sicher für ein qualitativ hochwertiges Paket.
Einen letzten Werkzeugsatz benötigt man um dann die Pakete der breiten Öffentlichkeit zugänglich zu machen. Einen GPG-Key und rpm zum Signieren der Pakete ist erstmal Grundvoraussetzung und sollte genutzt werden um aufzuzeigen, dass ein Paket qualitätsgesichert ist. Createrepo kann dann genutzt werden um die Pakete in einem Repository zu veröffentlichen. Createrepo kann auch mit Gruppeninformationen für die Installation versehen werden, diese können mit dem Tool yum-groups-manager erstellt werden.
Wer eine GUI braucht installiert sich das passende Modul in Eclipse. Wer einen Buildserver braucht den mehrere Package Maintainer gleichzeitig nutzen können, sollte sich den auf mock aufbauenden Buildserver koji anschauen, den das Fedora Projekt nutzt, oder er schaut sich den Werkzeugkasten der Suse-Welt an bis hin zum OpenSuse-Buildserver, alternativ gibt es aber auch kommerzielle Produkte für denjenigen der Support braucht. Aber mit all diesen Werkzeugen habe ich bisher wenig Erfahrung sammeln dürfen.
Ich hoffe dieser kleine Überblick hilft dem ein oder anderen. Auf meiner Agenda für diese kleine Serie steht nun noch eine kleine Einführung in Red Hats Software Collection als Konzept für Pakete zur parallelen Installation von Softwareversionen.
0 Kommentare