Soll ich meine Haskell-App über die RPM SPEC-Datei erstellen oder versuchen, eine (reproduzierbare) Binärdatei aus der CI-Pipeline zu verwenden?

Question

Ich habe seit 20 Jahren kein RPM mehr von Grund auf neu erstellt. Wir können also effektiv „nie“ sagen.

[Bearbeiten] Die Anforderung an RPMs besteht darin, Rollbacks, Versionskontrolle und dergleichen bereitzustellen. Das ist nicht verhandelbar.

Ich muss eine einzelne Binärdatei und eine einzelne Konfigurationsdatei installieren. Es müssen einige Einstellungen mit Benutzerkonten und Verzeichnissen vorgenommen werden, die meiner Meinung nach unkompliziert sein sollten.

Wenn ich im RPM-Build-Prozess einen getesteten, reproduzierbaren Build haben möchte, muss ich unsere CI-Pipeline-Schritte replizieren. Nicht trivial. Im Idealfall kann ich die gewünschten Dateien einfach von einem anderen Ort abrufen:

%prep
cp ${somefile} ${another file} $RPM_SOURCE_DIR
%setup
:

Ist das möglich? Oder übersehe ich eine offensichtliche Lösung?

Danke.

Answer 1

Aus meiner Sicht hängt es ein wenig davon ab, was Sie genau anstreben:

Linux-Distributionen wie Fedora erwarten für ihre Distributions-Builds tatsächlich, dass die Software aus dem Quellcode unter Verwendung der Spezifikationsdatei (innerhalb eines geschlossenen Buildsystems, in dem auch die zum Erstellen verwendeten Pakete/Komponenten dokumentiert sind) erstellt wird, und betrachten dies als bewährte Vorgehensweise, auch um eine größtmögliche Reproduzierbarkeit zu erreichen.

Sie können jedoch tatsächlich einfach vorgefertigte Binärdateien abrufen und diese in einer Spezifikationsdatei verwenden, um ein RPM-Paket zu erstellen. Verkürztes Beispiel für Ihr Szenario:

# […]
Source0: <binary file>
Source1: <config file>

# […]

%prep
%setup -q -c -T

%build

%install
install -D -p -m 0755 %{SOURCE0} $RPM_BUILD_ROOT%{_bindir}/%{name}
install -D -p -m 0644 %{SOURCE1} $RPM_BUILD_ROOT%{_sysconfdir}/%{name}.conf

# […]

Dies könnte zwar funktionieren, Sie sollten jedoch explizit prüfen, ob die Abhängigkeiten des resultierenden RPM-Pakets geeignet sind ( rpm -qp --requires <…>.rpm) oder ob Laufzeitabhängigkeiten fehlen. Beim Erstellen des RPM-Pakets gibt es häufig Optionen oder Parameter zur Kompilierungszeit (z. B. CFLAGSoder LDFLAGSin C geschriebene Software) sowie Nachbearbeitungsskripte (z. B. /usr/lib/rpm/(redhat/)brp-*), die distributionsspezifische Dinge hinzufügen und/oder Laufzeitabhängigkeiten für Sie extrahieren. Dies kann für Sie relevant sein oder auch nicht (und einige Nachbearbeitungsskripte funktionieren möglicherweise auch für vorgefertigte Binärdateien, andere jedoch nicht aufgrund fehlender Compileroptionen). Obwohl ich viel Software verpacke, habe ich keine Erfahrung mit Haskell, aber wenn man sich einige Fedora-Pakete ansieht, gibt es RPM-Pakete mit Laufzeitabhängigkeiten (und wenn es Laufzeitabhängigkeiten gibt, müssen diese von RPM-Paketen erfüllt werden, denn so funktioniert RPM; und es reicht nicht aus, die passende Bibliothek irgendwo auf Ihrem Dateisystem zu haben, denn RPM weiß nichts davon, es sei denn, es wird von einem RPM-Paket bereitgestellt). Daher kann das Erstellen eines RPM-Pakets aus vorgefertigten Binärdateien zu einem RPM-Paket ohne geeignete Abhängigkeiten führen, was sich später als Laufzeitfehler herausstellen kann.

Zum obigen Beispiel: Obwohl SourceX:eine URL angegeben werden kann, rpmbuildwerden diese Dateien beim Erstellen des RPM-Pakets dennoch auf der Festplatte im SOURCESVerzeichnis erwartet (wie sie in das SOURCESVerzeichnis gelangen, bleibt Ihnen überlassen).

Da Sie nicht erwähnt haben, auf welche Linux-Distribution Sie abzielen, verlinke ich FedorasHaskell-Verpackungsrichtlinien hier, was vielleicht weitere Inspiration bietet, vielleicht aber auch nicht. Und ja, RPM-Pakete können verteilungsübergreifend sein, was in der Praxis oft zu statischen Binärdateien innerhalb der RPM-Pakete führt, da es auf verschiedenen Linux-Distributionen oft unterschiedliche Bibliotheks-/Paketversionen gibt.