Im zweite Teil meiner Recherche (dieser Beitrag) habe ich rausgekriegt, wie ich in Solus Software-Pakete erzeugen kann. Im Prinzip ist es alles einfach, sobald man das mit den Software-Paketen einmal verstanden hat. Für mich war es eine gewisse Lernkurve.

Also: Ein Software-Paket ist in Solus eine Datei mit .eopkg-Endung, letztlich eine Archiv-Datei. .eopkg-Pakete sind strukturell nicht viel anders als Debians .deb-Pakete. Ein solches Paket enthält genau die Software, die auf dem Zielsystem installiert werden muss. Das sind in der Regel binäre Programm-Dateien, ggf. mit Konfigurationsdateien. Das können aber auch Bash-Skripte, Python-Skripte usw. sein, wenn denn das die Software ist. Pakete generiert man in Solus auf verschiedene Weisen:

  • mit solbuild;
  • mit eopkg;
  • mit ypkg und ypk-build.

solbuild

Vorzugsweise soll ich solbuild verwenden. solbuild erwartet den Quelltext eines Programms als tar-Archiv und erzeugt nach Maßgabe einer Steuerungs- und Konfigurationsdatei namens package.yml ein eopkg-Paket aus dem tar-Archiv. Das ist im Detail ein wenig kompliziert, aber gut erklärt. Ich muss also solbuild installieren, meine Software als tar-Archiv mit einer package.yml-Datei vorbereiten und schon habe ich ein eopkg-Paket.

solbuild verwendet ein Image eines Solus-Basis-Systems, das in einer chroot-Umgebung ausgeführt wird. Das ist gut, weil dadurch eine ‘saubere’ Build-Umgebung vorhanden ist und etwaige lokale Besonderheiten des Systems, auf dem ich solbuild ausführe, unberücksichtigt bleiben. Das garantiert, dass das erzeugte Paket später auch auf allen anderen Solus-Systemen installiert werden kann. Gut ist auch, dass man nicht unbedingt Solus braucht, um mit solbuild zu arbeiten, sondern dass solbuild auch auf anderen Linux-Systemen laufen kann.

Da eine chroot-Umgebung aber nur ein klein wenig von dem System abstrahiert, in dem sie ausgeführt wird, muss das System, auf dem solbuild läuft, dieselbe Systemarchitektur haben, die Solus voraussetzt. Andernfalls würde bereits das Solus-Image, das verwendet wird, nicht ausführbar sein. Das bedeutet praktisch, dass ich solbuild nicht auf einem Raspberry Pi ausführen kann, weil der keine x86-Architektur hat und in aller Regel mit 32 Bit betrieben wird.

ypkg und ypk-build

ypkg (und darüber indirekt ypkg-build) soll ich laut der Man-Page von ypkg nicht verwenden:

Note that you should not use ypkg(1) directly unless completely unavoidable. Instead, you should be using solbuild(1) for isolated build environments.

eopkg

Das Generieren von eopkg-Paketen mit eopkg ist, wenn ich das richtig verstehe, ein historisches Überbleibsel aus früheren Zeiten. Dieser Weg wird verwendet, wenn eopkg-Pakete aus Software erzeugt werden sollen, die nicht als Quelltext vorliegen. Pro Paket gibt es eine XML-Datei und meistens auch eine Python-Datei, die die package.yml-Datei der eopkg-Pakete ersetzen. Dieser Weg soll durch Snaps/Flatpaks/wasauchimmer ersetzt werden, ist also nicht besonders zukunftssicher.

Ich installiere also jetzt mal solbuild auf meinem Zenbook und versuche, eines meiner einfachen Projekte in eine eopkg-Datei zu verwandeln. Ich werde berichten.