openSUSE:Paketbau Richtlinien

Paketbau

Paketbau Richtlinien - Richtlinien zur Bezeichnung von Paketen - Richtlinien für Spezifikationsdateien - Richtlinien für Patches - Sicherheitsrichtlinien - Richtlinien für Paketgruppen - Paketbau Prüfungen - Kategorien für Desktopmenüs - RPM Makros - Init-Skripte - kleine Skript-Schnipsel - Paketbau Perl - Paketbau-Richtlinie für mehrfach benutzte Bibliotheken - Paketabhängigkeiten - Paketbau von Python-Software - Paketbau Richtlinien für mehrere Versionen

Die Paketbau Richtlinien regulieren alle wesentlichen Details des Paketbaus für eine openSUSE Distribution. Es gibt grundsätzliche Regeln, Regeln über gesetzliche Aspekte eines Paketes, über spezielle Paketfunktionen und über spezielle Pakettypen.

Es liegt in der Verantwortung des Gutachters, spezielle Probleme mit einem Paket aufzuzeigen und es liegt in der Verantwortung des Paketbauers, damit umzugehen. Der Gutachter und der Paketbauer arbeiten zusammen, um die Schwierigkeit des Problems zu bestimmen - entweder sie blockieren ein Paket oder es kann daran weiter gearbeitet werden, nachdem sich das Paket im Repository befindet.
Die Paketbau Richtlinien sind eine Zusammenstellung gewöhnlicher Probleme und des Schwierigkeitsgrades, der auf sie angewendet werden sollte. Diese Richtlinien sollten nicht ignoriert werden aber auch nicht blind befolgt werden. Wenn Sie glauben, dass Ihr Paket von einem Teil der Richtlinien ausgeschlossen werden, bringen Sie dieses Problem auf die openSUSE-Paketbau-Mailingliste.
Bitte beachten Sie auch, dass im Build Service eine ganze Menge Regeln durchgesetzt werden oder über sie gewarnt wird, nach einem erfolgreichen Bau mit einem Werkzeug genannt rpmlint. Der Paketbauer sollte immer seine Ausgabe prüfen, um über gewöhnliche Paketbau-Fehler informiert zu sein und um Hinweise zu erhalten, wie der Paketbau verbessert werden könnte. Lesen Sie auch die Paketbau Prüfungen. Hier finden Sie Erklärungen über die meisten Warnungen von rpmlint. Diese Seite enthält ebenso Anweisungen, wie Falschmeldungen abgeschaltet werden können.

Grundsätzliche Regeln

Es gibt einige grundsätzliche Spielregeln die befolgt werden müssen.

Keine Einbeziehung von vorgefertigten Binärprogramme oder Bibliotheken

Alle Binärprogramme oder Bibliotheken, die in openSUSE Pakete einbezogen werden, müssen aus dem Quelltext gebaut werden, der in den Quellpaketen enthalten ist. Das ist eine Anforderung aus folgenden Gründen:

Sicherheit: Vor-gepackte Binärprogramme und Bibliotheken, die nicht aus aus dem Quelltext gebaut sind, könnten irgendeinen arglistigen oder gefährlichen Inhalt haben oder sind einfach defekt. Ebenso ist es funktionstechnisch unmöglich, sie zu verbessern oder Fehler zu beheben.
Compiler Flags: Vor-gepackte Binärdateien und Bibliotheken, die nicht aus den Quellen gebaut werden enthalten wahrscheinlich nicht die Standard openSUSE Compiler Flags für die Sicherheit und zur Optimierung.

Wenn Sie Zweifel haben, ob etwas als Binärprogramm oder als Bibliothek zu betrachten ist, finden Sie hier einige unterstützende Kriterien:

Ist es anzeigbar? Wenn nein, dann ist es wahrscheinlich ein Binärprogramm.
Enthält es Erweiterungen mit .so, .so.#, .so.#.# oder .so.#.#.#? Wenn ja, ist es wahrscheinlich eine Bibliothek.
Wenn Sie Zweifel haben, fragen Sie auf der openSUSE-packaging-Mailingliste nach.

Pakete, die nicht-offene Quellkomponenten zum Bau erfordern, sind ebenso nicht erlaubt (z. B. wenn proprietäre Compiler benötigt werden).

Ausnahmen

Einige Programme (gewöhnlich stehen sie mit den Compilern oder Cross-Compiler-Umgebungen in Verbindung) können nicht ohne die Verwendung von Preprozessoren oder Entwicklungsumgebungen (open source) gebaut werden. Wenn Sie ein Paket haben, auf das dieses Kriterium zutrifft, bitten Sie das openSUSE Paketbau-Gremium um Erlaubnis.
Eine Ausnahme wird für binäre Firmware gemacht, so lange es den dokumentierten Anforderungen entspricht: BinaryFirmware.

Bündelung mehrerer Projekte

Beim Bau von Paketen in openSUSE sollten alle Anstrengungen unternommen werden, um die Bündelung mehrerer getrennter Software-Projekte in einem einzigen Paket zu vermeiden.

Spezielle Richtlinien

Die Regeln, die auf den Inhalt von Spezifikationsdateien anzuwenden sind, sind in einem getrennten Dokument enthalten, das Richtlinien für Spezifikations-Dateien genannt wird.

Prozessorarchitekturen

Alle openSUSE Pakete müssen erfolgreich in binäre RPM-Dateien, auf mindestens einer der unterstützten Architekturen, das sind i586 und x86_64, kompiliert und gebaut werden. Der Paketersteller sollte jede Bemühung unternehmen, um Pakete für beide unterstützten Architekturen zu bauen. Quelltexte, die nicht kompiliert oder verarbeitet werden müssen - ebenso prozessorunabhängige Code (noarch), sind nennenswerte Ausnahmen.

Verschiebbare Pakete

Die Verwendung einer RPM-Einrichtung zur Erzeugung verschiebbarer Pakete ist streng untersagt. Es ist schwierig, sie ausreichend zum Laufen zu bringen, unmöglich vom Installierer oder von Zypper und YaST zu nutzen und nicht grundsätzlich notwendig, wenn andere Paketbau-Richtlinien befolgt werden. Wie auch immer, in dem unwahrscheinlichen Fall, dass Sie einen guten Grund haben, ein Paket verschiebbar zu machen, MÜSSEN Sie diese Absicht und Begründung in der Anfrage zur Paket-Prüfung angeben.

Rechtliches

Unerlaubte Software

Anwendungen (oder andere Software), die auf der schwarzes Liste des Build Service stehen, sind nicht zum Paketbau erlaubt.

Lizenzierung

Die Lizenzierung muss OSI konform sein. Die Liste der Open Source Lizenzen (Lizenzen mit Bezeichnung) führt die Lizenzen auf, die von der Open Source Initiative (OSI) erlaubt sind. openSUSE und verschiedene andere Distributionen haben einen allgemeinen Satz von Lizenz-Abkürzungen im SPDX Projekt standardisiert. Es scheint, dass die OSI dies auch aufgegriffen hat.

Bitte verwenden Sie die standardisierten Kurzbezeichnungen, wie sie von der OSI (oder SPDX) Lizenz-Liste spezifiziert sind. Weiterhin führte SPDX eine Mini-Syntax zur Erklärung mehrerer Lizenzen ein. Zum Beispiel, wenn eine Software, die Sie packen wollen, unter GPL Version 2 oder später und der MIT-Lizenz zweifach lizenziert ist, verwenden Sie Folgendes in Ihrer Spezifikations-Datei:

Lizenz:     GPL-2.0+ oder MIT

Sind Sie sich bewusst, dass die SPDX-Mini-Syntax auch 'und' und Klammerzeichen für komplexere (z. B. eigenartigere) Fälle (denken Sie einfach an sie als einen Boole'schen Ausdruck ;-)) unterstützt. Wenn Sie in Zweifel sind, sind Sie so frei und fragen unser Rechtsteam.

Siehe auch:

http://en.opensuse.org/openSUSE:Accepted_licences
http://license.opensuse.org

Kode kontra Inhalt

Es ist wichtig, einen Unterschied zwischen einem vom Computer ausführbaren Kode und dem Inhalt zu machen. Während der Kode erlaubt ist (natürlich angenommen, dass er eine open Source kompatible Lizenz besitzt, nicht rechtlich fragwürdig usw. ist), sind nur einige Arten Inhalten erlaubt. Die Regel ist: Wenn der Inhalt die Nutzererfahrung erhöht, dann ist der Inhalt OK, um in openSUSE gepackt zu werden. Das bedeutet beispielsweise: Schriftarten, Themen, Bilder (Clipart) und Hintergrundbilder (Wallpaper) sind OK. Der Inhalt muss noch auf Einfügungen überprüft werden. Er muss eine open Source Lizenz haben und darf nicht gesetzlich fragwürdig sein. Zusätzlich gibt es verschiedene Einschränkungen für den Inhalt:

Der Inhalt darf nicht pornografisch sein, oder Nacktheit enthalten, weder animiert, simuliert noch fotografisch. Es gibt bessere Orte im Internet, um Porno zu erhalten.
Der Inhalt sollte nicht offensiv, diskriminierend oder abfällig sein. Wenn Sie nicht sicher sind, ob auf einen Teil des Inhalts etwas hiervon zutrifft, dann trifft es wahrscheinlich zu.

Einige Beispiele für erlaubte Inhalte:

Clipart für die Verwendung in Büroanwendungen
Hintergrundbilder (nicht-offensive, nicht diskriminierend, mit Erlaubnis zur freien Veröffentlichung)
Schriftarten (unter einer open Source Lizenz, ohne Eigentumsrechte/rechtliche Bedenken)
Spielebenen werden nicht als Inhalt betrachtet, da Spiele ohne Ebenen keine Funktion hätten.
Sounds oder Grafiken, die im Quell-Tarball enthalten sind, die das Programm oder das Thema verwendet (oder die Dokumentation verwendet) sind akzeptabel
Spiel-Musik oder Audio-Inhalt ist erlaubt, so lange wie der Inhalt ohne Einschränkung frei verteilbar ist.
Beispieldateien, die im Quell-Tarball enthalten sind, werden nicht als Inhalt betrachtet.

Einige Beispiele für nicht erlaubte Inhalte:

Bilddateien von Comic-Büchern
religiöse Texte
mp3-Dateien (Patentschutz)

Wenn Sie unsicher sind, ob etwas als erlaubter Inhalt betrachtet werden kann, fragen Sie bitte auf der Mailingliste von openSUSE-packaging nach.

Paketfunktionen

Init-Scripte

Momentan werden nur Init-Scripte vom SystemV-Style in openSUSE unterstützt. Es gibt detaillierte Richtlinien für SystemV-Style-Init-Scripte unter Paketbau Init-Skripte.

Desktop-Dateien

Wenn ein Paket eine Anwendung mit grafischer Oberfläche enthält, dann benötigt es auch eine passende Datei .desktop. Für den Zweck dieser Richtlinie: eine Anwendung mit grafischer Oberfläche ist definiert als eine Anwendung, die ein X-Fenster (X-window) zeichnet und innerhalb dieses Fensters läuft. Installierte .desktop-Dateien MÜSSEN die Desktop-Eingabe-Spezifikation befolgen. Eine besondere Aufmerksamkeit ist auf den richtigen Gebrauch der Einträge von Name, GenericName, Categories und StartupNotify zu richten.

Icon-Symbol in Desktop-Dateien

Das Icon-Symbol muss die Grundbezeichnung der Icon-Datei(en) haben, damit es die Icon-Beschriftung erlaubt:

Icon=comical

Es nimmt .png als Standard an, dann versucht es .svg und schließlich .xpm.

Erstellen der Datei `.desktop`

Wenn das Paket nicht wirklich seine eigene .desktop-Datei enthält und installiert, müssen Sie Ihre eigene erstellen und sie als Quelle einbinden (z.B. Source3: %name.desktop). Die Inhalte der Beispiel- .desktop-Datei (comical.desktop) sind:

[Desktop Entry]
Name=Comical
GenericName=Comic Archive Reader
Comment=Open .cbr & .cbz files
Exec=comical
Icon=comical
Terminal=false
Type=Application
Categories=Graphics;

Verwendung von `%suse_update_desktop_file`

Es ist nicht so einfach, nur die Datei .desktop in das Paket einzubinden. Man MUSS %suse_update_desktop_file in der Sektion %install laufen lassen und BuildRequires: update-desktop-files heranziehen, um zu helfen, die Sicherheit der Datei .desktop und die Einhaltung der Spezifikation sicher zu stellen. %suse_update_desktop_file MUSS verwendet werden, wenn das Paket die Datei nicht installiert oder wenn Änderungen an der Datei .desktop gewünscht sind (so wie das Hinzufügen oder Löschen von Kategorien usw.). Einige Beispiele zur Anwendung:

Desktop-Datei prüfen

%suse_update_desktop_file %{name}

Desktop-Datei installieren und Kategorien ändern

%suse_update_desktop_file -r %{name} System Utility Core GTK FileManager

Benutzer und Gruppen

Beachten Sie für den Moment, dass wir primär den Fall ansprechen, bei dem die Eintragung von Bezeichnungen für Benutzer/Gruppe in uids/gids dynamisch entschieden wird durch Zielsysteme während der Paket-Installations-Zeit. Einige Optionen für Systemadministratoren, diese Eintragungen statisch zu machen, obwohl die Paket-Skripte ein dynamisches Schema verwenden, werden unten ebenso diskutiert und weitere werden untersucht, einschließlich der Möglichkeiten, die Eintragung während der Bauzeit statisch zu machen.

Um Benutzer und Gruppen in Paketen zu erstellen, verwenden Sie:

Requires(pre): pwdutils

[...]

%pre
getent group GROUPNAME >/dev/null || groupadd -r GROUPNAME
getent passwd USERNAME >/dev/null || useradd -r -g GROUPNAME -d HOMEDIR -s /sbin/nologin -c "user for PACKAGENAME" USERNAME
exit 0

[...]

HOMEDIR sollte gewöhnlich ein Verzeichnis sein, das vom Paket erzeugt und besessen wird, mit geeignet eingeschränkten Erlaubnissen. Eine gute Wahl für die Lokalisierung des Verzeichnisses ist das Datenverzeichnis des Paketes oder unter /var wie /var/cache/NAME oder /var/lib/NAME, für den Fall sie hat eine.

Benutzerkonten, die von Paketen erstellt werden, werden selten für interaktives Anmelden verwendet und sollten /bin/false oder /sbin/nologin grundsätzlich als Shell des Benutzers verwenden.

Der Befehl exit 0 am Ende wird zum %pre Skript-Eintrag zurück führen, auch wenn die Erstellung von Benutzer/Gruppe aus irgendeinem Grund fehlschlägt. Das ist suboptimal, aber hat weniger Potential für systemweite Zusammenbrüche, als ihm zu erlauben fehl zu schlagen. Wenn user/group zu der Zeit, zu der das Pakete ungepackt ist, nicht zur Verfügung steht, wird RPM diese Dateien mit Rootrechten versehen.

getent läuft vor groupadd/useradd, um zu prüfen, ob der/die Benutzer/Gruppe, der/die erstellt werden soll, bereits vorhanden sind, und wenn ja soll die Erstellung übersprungen werden. Das wird gemacht, um die Möglichkeit für die lokalen Systemadministratoren zu unterstützen, user/group vorher zu erstellen, für den Fall, dass sie einen vordefinierten statischen UID/GID-Eintrag für diese Benutzer wünschen.

groupadd/useradd in %pre läuft immer — sowohl bei den ersten Installationen und als auch bei Aktualisierungen. Das wird ermöglicht, indem die Prüfungen getent gemacht werden. Es soll die Dinge beheben, wenn user/group verschwunden sein sollte, wenn das Paket aktualisiert wurde aber ursprünglich installiert war (wie Dateierlaubnisse bei Aktualisierungen usw. zurück gesetzt werden).

Benutzer oder Gruppen, die von den Paketen erstellt werden, werden niemals entfernt. Es gibt keinen normalen Weg, um zu prüfen, ob Dateien, die den Benutzern/Gruppen gehören, zurück gelassen werden - und wenn es so wäre, was würden wir mit ihnen machen? Wenn wir diese zurück lassen, mit Eigentumsrechten, die auf nicht vorhandene Benutzer/Gruppen weisen, könnte zu Sicherheitsproblemen führen, wenn später ein semantischer Benutzer/Gruppe ohne Bezug erstellt wird und die UID/GID wieder verwendet. Ebenso könnte in einigen Einstellungen die Löschung von Benutzer/Gruppe unmöglich sein oder nicht erwünscht, zum Beispiel, wenn eine gemeinsame entfernte Benutzer/Gruppen Datenbank verwendet wird. Die Bereinigung von unbenutzten Benutzern/Gruppen wird dem Systemadministrator überlassen, sich darum zu kümmern, wenn sie es so wünschen.

In manchen Fällen ist es wünschenswert, nur eine Gruppe ohne ein Benutzerkonto zu erstellen. Gewöhnlich ist das, weil es einige System-Ressourcen gibt, zu denen wir Steuer-Zugang haben wollen, indem wir diese Gruppe verwenden. Und ein separates Benutzerkonto würde keinen Mehrwert bringen. Beispiele solche gewöhnlichen Fälle schließen Spiele (aber nicht darauf beschränkt) ein, dessen Ausführbarkeit mit der Absicht zur Teilung von High-Score-Dateien gesetzt sind, oder ähnlichem und/oder für Software, die besondere Erlaubnisse auf einige Hardware-Treiber benötigen. Und es wäre ungeeignet, diese allen System-Benutzern zu gewähren, auch nicht denen, die auf der Konsole angemeldet sind. In diesen Fällen wenden Sie die groupadd-Teile des obigen Rezepts an.

Beachten Sie, dass die Praxis zur Nichterstellung von Benutzer/Gruppen, wenn sie bereits bestehen, einen Nachteil hat, wenn möglicherweise ohne Bezug aber zufälligerweise mit gleicher Bezeichnung vorhandene Systembenutzer und/oder Gruppen unnötigerweise und nicht wünschenswert Zugang zu Sachen in einem Paket erhalten, das die gleiche Benutzer/Gruppen-Bezeichnung verwendet. Diese Version der Benutzer/Gruppen-Richtlinien spricht das Problem in keiner Weise an, aber es ist möglich, dass zukünftige Revisionen das tun werden, wenn ein ausreichend guter Weg gefunden wurde, das zu tun.

Flicken (Patches)

Siehe Paketbau-Richtlinien für Flicken.

Unterstützung mehrerer Paket-Versionen

Siehe Unterstützung der Installation mehrerer Paket-Versionen

GConfe-Skripte

SuSEfirewall2 Service-Definitionen

Paket-Typen

Einige Anwendungen besitzen spezielle Richtlinien, die für sie geschrieben wurden und in ihren eigenen Paketen in der Paketbau/Hierarchie angeordnet sind.

32bit (baselib) Pakete

en:openSUSE:Build_Service_baselibs.conf

Markenzeichen

Debuginfo

Pakete sollten brauchbare -debuginfo-Pakete erzeugen oder sie deaktivieren, wenn es nicht möglich ist, brauchbare zu generieren. Wenn ein -debuginfo-Paket deaktiviert wurde, ist laut Spezifikation eine Erklärung gefordert. -debuginfo-Pakete werden in einem gesonderten Dokument detaillierter diskutiert: [1].

Eclipse Plugins

Emacs

Schriftarten (Fonts)

Schriftarten in universellen Formaten, wie Type1, OpenType TT (TTF) oder OpenType CFF (OTF) sind Thema spezieller en:openSUSE:Packaging_Fonts und sollten niemals in ein persönliches Anwendungsverzeichnis sondern in die System weiten Schrift-Paketquellen gepackt werden.

Spiele

Wie man Spiele packt, wird unter en:openSUSE:Packaging_Games erklärt.

GNOME

Go

Wie Go-Software zu packen ist, wird unter en:openSUSE:Packaging_Go erklärt.

Haskell

Java

Wie Java-Software zu packen ist, wird unter en:openSUSE:Packaging_Java erklärt.

JPackage

Lisp

Mono

Mozilla

OCaml

Erweiterungen für OpenOffice.org

PAM (Pluggable Authentication Modules)

Perl

Wie Perl-Software zu packen ist, wird unter openSUSE:Packaging_Perl erklärt.

PHP

Wie PHP-Software zu packen ist, wird unter en:openSUSE:Packaging_PHP erklärt.

Python

Wie Python-Software zu packen ist, wird unter openSUSE:Packaging_Python erklärt.

Ruby

Wie Ruby-Software zu packen ist, wird unter en:openSUSE:Packaging_Ruby erklärt.

wxWidgets

Wie wxWidgets-Software zu packen ist, wird unter en:openSUSE:Packaging_wxWidgets erklärt.

Bibliotheken

Gemeinsam benutzte Bibliotheken

Wie gemeinsam benutzte Bibliotheken zu packen sind, wird unter openSUSE:Shared library packaging policy erklärt.

Statische Bibliotheken

Pakete, die Bibliotheken enthalten, sollten statische Bibliotheken so weit wie möglich ausschließen (z.B. durch die Konfiguration mit dem Schalter --disable-static). Statische Bibliotheken sollten nur unter besonderen Umständen einbezogen werden. Anwendungen, die mit Bibliotheken verknüpft werden, sollten so weit wie möglich mit gemeinsam benutzten Bibliotheken und nicht mit statischen Versionen verknüpft werden.

Libtool-Archive, foo.la Dateien, sollten nicht einbezogen werden. Pakete, die libtool verwenden, installieren diese standardmäßig, auch wenn Sie mit --disable-static konfigurieren. Sie müssen vor dem Packen entfernt werden. Das ist auf Fehlern in älteren Versionen von libtool oder von Fehlern in Programmen, die libtool verwendeten, zurück zu führen. Es gibt Umstände, unter denen es nicht immer möglich ist, *.la-Dateien zu entfernen, ohne das Programm zu modifizieren. In den meisten Fällen ist es ziemlich einfach, mit neueren Versionen zu arbeiten, um das Problem zu beheben. Beachten Sie, wenn sie ein Paket in einer stabilen openSUSE-Veröffentlichung aktualisieren und das Paket enthält bereits *.la-Dateien, sollte eine Beseitigung der *.la-Dateien wie eine API/ABI-Änderung behandelt werden. Mit anderen Worten: ihre Löschung ändert die Schnittstelle, die die Bibliothek an den Rest der Welt ausgibt und sollte nicht leichtfertig vorgenommen werden.

Ausnahme

Wir wollen in der Lage sein, heraus zu finden, welche Pakete statische Bibliotheken benutzen, damit wir entscheiden können, welche Pakete neu gebaut werden müssen, wenn zum Beispiel ein Sicherheitsmakel in einer statischen Bibliothek behoben wird. Wenn Sie wirklich statische Bibliotheken packen müssen, müssen Sie diese Richtlinien befolgen.

Statische Bibliotheken müssen in einem Unterpaket *-devel-static angeordnet werden, was das *-devel-Unterpaket erfordert. Die Abtrennung der statischen Bibliotheken von den anderen Entwicklungs-Dateien in *-devel, erlaubt es uns, diese Verwendung aufzuspüren, indem wir prüfen, welche Pakete das *-devel-static-Paket benötigen. Die Absicht besteht darin, wenn immer es möglich ist, die Pakete davon abzubringen statische Bibliotheken zu verwenden, sondern gemeinsam benutzte Bibliotheken, Requires in den *-devel-Subpaketen weglassen. Pakete, die explizit mit statischen Versionen verknüpft werden müssen, müssen dann BuildRequire: foo-devel-static, enthalten, so dass die Verwendung aufgespürt werden kann.

Wenn (und nur wenn) ein Paket gemeinsam benutzte Bibliotheken besitzt, die statische Bibliotheken benötigen, um zu funktionieren, können die statischen Bibliotheken in die *-devel-Subpakete einbezogen werden. Das devel-Subpaket muss einen virtuellen Provide für das *-devel-static-Paket haben. Und Pakete, die davon abhängen, müssen über BuildRequire das *-devel-static-Paket aufrufen.

Vervielfältigung von System-Bibliotheken

Aus verschiedenen Gründen sollte ein Paket weder eine lokale Kopie einer Bibliothek, die auf dem System vorhanden ist, einbeziehen noch gegen diese gebaut werden. Das Paket sollte geflickt (patched) werden, um die System-Bibliotheken zu verwenden. Das verhindert das Weiterbestehen alte Fehler und Sicherheitslöcher, nachdem die Kern-System-Bibliotheken repariert wurden.

Tcl

Web-Anwendungen

Web-Anwendungen, die in openSUSE gepackt sind, sollten ihren Inhalt in /www/%name</tt> legen und NICHT in /var/www. Das wird gemacht wegen:

/var ist vorgesehen, variable Daten- und Log-Dateien zu enthalten. /srv/www ist viel besser dafür geeignet.
Benutzer könnten bereits einen Inhalt in /var/www haben. Und wir wollen nicht, dass irgend ein openSUSE-Paket da oben drauf stellt.
/var/www wird nicht mehr vom Hierarchie-Standard des Dateisystems spezifiziert.

Vala

Wie man Vala-Versionen in Spezifikations-Dateien herausfindet

Wir nehmen an, dass Sie nicht Vala bauen. Wenn ja, dann ist die Vala-Version von Ihnen selbst definiert und kann einfach mit verwende %{version} Kennzeichen benannt werden. Das Problem existiert eben nicht. Nun haben wir aber folgende unangenehme Situation:

Das Paket ist mit Vala gebaut worden, und ist gut gebaut worden unter allen Versionen von Vala (So müssen Sie nicht die Lilie mit der Marke BuildRequires: vala >= 0.14 vergolden). Aber Sie müssen noch immer die Versionsnummer von Vala herausfinden und verwenden.

Hier hat der Build Service einen Flaschenhals. Für den Moment kann Vala nicht einfach mit BuildRequires: vala einbezogen werden und seine Version einfach und naiv mit einer automatischen Marke wie %{py_ver} oder %{perl_version} exportiert werden, wie es bei Perl oder Python funktioniert. Manche Pakete müssen die Nummer von Vala wissen, damit sie funktionieren (Babl oder Gegl werden standardmäßig die Datei .vapi unter /usr/share/vala installieren. Aber dieses Verzeichnis ist bedeutungslos in einem Standard openSUSE System. openSUSE verwendet ein Verzeichnis, das eine Vala-Versions-Nummer anhängt, wie /usr/share/vala-0.14. Nun es ist die Verantwortung des Paketbauers, sie aus dem Standard-Paket-Verzeichnis in das abrufbare von openSUSE zu verschieben.)

Natürlich könnten Sie, indem Sie die Kennzeichnung %if 0?{%suse_verion} >= 1140 verwenden, sie in das Verzeichnis verschieben, das mit einer Standard-Vala-Versions-Nummer versehen ist, das standardmäßig in der Version 1140 von openSUSE installiert ist. Aber es wird Ihre Spezifikations-Datei riesig und nicht mehr wartbar machen (Sie müssen solch eine Sektion für jede openSUSE-Version hinzufügen).

Nun verwenden wir die selbstdefinierte Funktion %define in der Spezifikations-Datei wie folgt:

 #Import der Vala-Abhängigkeit 
 BuildRequires: vala
 #definiere die Funktion zum Export der Vala-Versions-Nummer
 %define vala_version %(rpm -q --queryformat='%%{VERSION}' vala | sed 's/\.[0-9]*$//g')

Wir verwenden rpm -q --queryformat='%%{VERSION}' vala, um die komplette Vala-Versions-Nummer 0.14.0 zu erhalten, die auf einem Standard-RPM-Weg installiert ist, bevor der aktuelle Bauprozess beginnt. Das ist so, damit der Kode funktioniert. Und dann verwenden Sie das Shell-Kommando sed mit Unterstützung von Regex, um den Anhang .0 abzutrennen und das Ergebnis zur Variablen vala_version zu exportieren, die leicht mit %{vala_version} aufgerufen werden kann. Z.B.:

 #erstelle ein neues Verzeichnis. -pv bedeutet Export Verzeichnisse in die Log-Datei für spätere Fehlersuche 
 #und erstelle es automatisch, wenn das Elternverzeichnis nicht vorhanden ist. 
 %{__mkdir} -pv %{buildroot}%{_datadir}/vala-%{vala_version}/
 #verschiebe die Dateien
 %{__mv} %{buildroot}%{_datadir}/vala/* %{buildroot}%{_datadir}/vala-%{vala_version}/
 #lösche den Original-Ordner
 %{__rm} -rf %{buildroot}%{_datadir}/vala/

Auch im %files Abschnitt könnten Sie

 %dir %{_datadir}/vala-%{vala_version}/
 %{_datadir}/vala-%{vala_version}/*

verwenden, um Ihre Spezifikations-Datei zu vereinfachen.

Weil jede Datei unter %{buildroot} hierarchisch in die endgültige RPM-Ausgabe gepackt werden wird. Nun tauchen Ihre benutzerfreundlichen Pakete mit +1 auf.