Paketbaurichtlinien für R

Alle R-Pakete erzeugen automatisch standardisierte Requires- und Provides-Einträge mithilfe eines Generators in R-rpm-macros:

wobei $pkg der Name des Upstream-Pakets und $version die RPM-kompatible Version ist, wie unter [Versioning] beschrieben.

Der Paketierer MUSS die generierten Requires-Einträge auf Korrektheit prüfen. Alle harten Abhängigkeiten (LinkingTo, Depends, Imports von R) MÜSSEN in der Zielversion von Fedora auflösbar sein.

Pakete MÜSSEN BuildRequires: R-devel deklarieren, wodurch die notwendigen R-rpm-macros eingebunden und die Entwicklungsumgebung (Compiler, Bibliotheken usw.) eingerichtet wird.

Falls für den Bauvorgang weitere Bibliotheken und Hilfsprogramme (z.B. cmake) benötigt werden, MÜSSEN diese explizit als BuildRequires deklariert werden.

Bauabhängigkeiten von anderen R-Paketen werden automatisch durch das Makro %R_buildrequires behandelt, das im Scriptlet %generate_buildrequires aufgerufen werden MUSS.

Gemäß den allgemeinen Richtlinien SOLLTEN Pakete nach Möglichkeit andere Abhängigkeiten aus den R-Paketquellen extrahieren. Werden gebündelte Abhängigkeiten verwendet, MÜSSEN diese als virtuelles Provides deklariert werden.

Manche R-Pakete stellen Header-Dateien unter dem Standardpfad R/library/$pkg/include bereit (definiert von CRAN und von R erwartet), so dass andere Pakete über LinkingTo darauf verlinken können. Das Paket Rcpp ist ein bekanntes Beispiel. Manchmal werden diese Header zur Bauzeit benötigt, manchmal sowohl zur Bau- als auch zur Laufzeit, und sind daher für die korrekte Funktion unerlässlich. Aus diesen und weiteren Gründen dürfen diese Header NICHT in ein -devel-Teilpaket ausgelagert werden.

Wenn ein bestimmtes Paket eine große Anzahl von Beispielen oder Dokumentationen enthält, die für die Funktionalität des Pakets nicht notwendig sind, KÖNNEN diese in ein Teilpaket ausgelagert werden, aber von Teilpaketen wird generell dringend abgeraten.

Die übrigen Scriptlets erwarten, dass die Paketquellen in einem nach dem Paket benannten Unterverzeichnis extrahiert werden. Daher MUSS in %prep beim Aufruf von %setup oder %autosetup die Option -c gesetzt werden.

Weiterer Code für Entbündelung, Fehlerbehebungen und Workarounds DARF hier platziert werden.

Das Makro %R_buildrequires MUSS im Scriptlet %generate_buildrequires aufgerufen werden, um die dynamischen BuildRequires zu erzeugen.

Testpakete wie testthat, die in Suggests deklariert sind, werden in %{__R_whitelist} auf die Whitelist gesetzt und von %R_buildrequires als BuildRequires hinzugefügt.

R-Pakete werden in einem einzigen Schritt über R CMD INSTALL erstellt und installiert. Daher MUSS der Abschnitt %build leer sein.

Es werden zwei Makros bereitgestellt, die im Abschnitt %install aufgerufen werden MÜSSEN. Zuerst erstellt %R_install das Paket und installiert es, dann generiert %R_save_files eine Liste der Dateien, die dem angegebenen importierbaren Modul entsprechen, und speichert diese als %{R_files}.

Das Makro %R_check MUSS im Abschnitt %check aufgerufen werden, um R-Paketprüfungen durchzuführen.

Gemäß den CRAN-Richtlinien MÜSSEN R-Pakete ohne weiche Abhängigkeiten funktionieren. Wenn Paketprüfungen fehlschlagen, weil weiche Abhängigkeiten bedingungslos verwendet werden (z.B. in Beispielen oder Tests), gilt dies als Fehler und SOLLTE an die Entwickler gemeldet werden. In der Zwischenzeit MUSS etwas implementiert werden, das das Problem umgeht:

Moduldateien MÜSSEN über die Option -f wie folgt hinzugefügt werden:

Falls erforderlich, SOLLTEN alle zusätzlichen Dateien, die sich außerhalb des Paketpfads befinden, anschließend explizit hinzugefügt werden.