Erstellen eines RPM-Pakets für Rosa Linux in der Praxis

Wenn Sie das Linux-Betriebssystem schon lange verwenden und sogar ein wenig über Programmierung wissen, müssen Sie das Programm möglicherweise früher oder später aus dem Quellcode kompilieren. Möglicherweise befindet sich das gewünschte Programm nicht in den Distributions-Repositorys. Oder das Programm hat eine alte Version in diesen Repositorys, und Sie benötigen die neueste. Oder Sie haben ein neues Programm erstellt und möchten es mit anderen Benutzern teilen.


Natürlich können Sie das Programm gemäß den Anweisungen installieren, die mit dem Quellcode geliefert wurden. Dann müssen Sie die Programmdateien manuell verwalten und ihre Abhängigkeiten überwachen. Es ist viel besser, ein Paket mit dem Programm zu erstellen und den im Betriebssystem integrierten Anwendungsmanager zu verwenden.


Ich hoffe, dieser Artikel hilft Ihnen dabei, schnell herauszufinden, wie Sie ein RPM-Paket für Rosa Linux oder eine andere Distribution erstellen, die den RPM-Paketmanager (Mandriva, RedHat) verwendet. Oder sag mir wenigstens, wo ich nach Informationen suchen soll.


Hier werde ich anhand eines einfachen Beispiels zeigen, wie RPM-Pakete auf meinem lokalen Computer erstellt werden. Wir werden das xkb-switch- Programm im Rosa Linux- Betriebssystem erstellen . Wir werden den Quellcode des Programms von GitHub übernehmen .








Ein bisschen über Rosa Linux


Rosa Linux ist eine Distribution, die von russischen Entwicklern erstellt und unterstützt wird. Es basiert auf Mandriva , aber mit einigen Funktionen. Ich verwende die 32-Bit-Version von Rosa Fresh R8 , die 2014 veröffentlicht wurde. Jetzt wird die R8- Version von Entwicklern nicht mehr unterstützt (Repositorys dafür werden nicht aktualisiert), aber sie funktioniert gut auf meinem Laptop, sodass ich keine neue Version installieren möchte.


Rosa Fresh R8 Verwendet den KDE4- Desktop. Alle Versionen des Distributionspakets verwenden urpm und urpm Manager, um Pakete mit Anwendungen zu verwalten. Die entsprechenden Befehle lauten rpm , urpmi , urpme , urpmq , urpmf .


Die Prinzipien zur Erstellung von Softwarepaketen werden normalerweise selten innerhalb derselben Linux-Distributionsfamilie geändert. Daher sollte das, was in diesem Artikel beschrieben wird, in allen Versionen von Rosa- Distributionen funktionieren.


Das Erstellen von Paketen unter Rosa Linux ist etwas einfacher als bei einigen anderen RPM- basierten Distributionen. Einige Punkte sind automatisiert und müssen nicht konfiguriert werden.




Ein bisschen über xkb-switch


Mir hat die Idee gefallen, das Plugin für den Vim-Texteditor xkbswitch zu verwenden , über den es einen Artikel über Habré gibt . Beim Verlassen des Eingabemodus wird das Tastaturlayout automatisch auf Englisch umgeschaltet und umgekehrt - auf den, auf dem der Text zuletzt eingegeben wurde -, wenn Sie den Eingabemodus erneut aufrufen. Damit dieses Plugin funktioniert, benötigen Sie das Programm xkb-switch , mit dem Sie das Tastaturlayout über die Befehlszeile und über Plugins für den Vim- Editor ändern können . Dieses Programm befand sich nicht in den Rosa Linux R8- Repositorys (und höchstwahrscheinlich wird es niemand hinzufügen, da die Distribution bereits alt ist und das Programm xkb-switch nicht sehr beliebt ist).




Einrichten, Finalisieren, Überprüfen des Programms


Oft ist es notwendig, die Kompilierung des Programms so zu konfigurieren, dass sie in einer bestimmten Distribution oder sogar für ein bestimmtes System korrekt funktioniert. Es kommt vor, dass ein Programm mit anderen Optionen oder mit der Unterstützung eines speziellen Treibers erstellt werden muss. Oder vielleicht möchten Sie Fehler im Programmcode beheben oder einfach überprüfen, ob es funktioniert. Zu diesem Zweck ist es besser, den Quellcode vor dem Erstellen des RPM-Pakets auf Ihren Computer zu kopieren, ihn zu kompilieren und die Funktionsweise des kompilierten Programms zu überprüfen.


Wenn Sie sicher sind, dass Sie die Projektdateien nicht ändern müssen, können Sie den ursprünglichen Quellcode von der Projektwebsite verwenden und sofort mit der Erstellung des Pakets fortfahren. Wenn Sie jedoch die Kompilierungseinstellungen ändern müssen, ist es normalerweise viel einfacher, die Datei im Quellordner (das sogenannte Makefile ) zu ändern, als sich dann mit den Kompilierungsbefehlsoptionen und dem internen Makrogerät für die Spezifikationsdatei zu befassen.




Überprüfen des Quellcodes ohne Ihr Profil auf GitHub


Wenn Sie mit dem Quellcode oder den Einstellungen für die Projektkompilierung arbeiten möchten, aber kein eigenes Profil auf GitHub haben oder es nicht verwenden möchten, können Sie den Quellcode einfach herunterladen und entpacken. In unserem Fall könnte es so aussehen (ich verwende den Ordner ~/Projects/cpp für C ++ - Quellcode):



 cd ~/Projects/cpp git clone https://github.com/ierton/xkb-switch.git 


Dadurch wird der Ordner ~/Projects/cpp/xkb-switch , der den Quellcode enthält. Anstatt git Sie das Archiv natürlich mit dem Programm herunterladen und entpacken.


Aus der Datei README.md im Projektordner lässt sich leicht cmake dass das Dienstprogramm cmake zum Erstellen des Programms verwendet wird. Wenn Sie die Kompilierungseinstellungen ändern müssen, befinden sie sich in unserem Fall in der Datei CMakeLists.txt . Und wir versuchen nur, das Programm zu kompilieren und zu überprüfen, ob es funktioniert. Welche Befehle Sie dafür verwenden müssen, wird in dieselbe README.md Datei im Stammverzeichnis des Projekts geschrieben.



 cd xkb-switch mkdir build && cd build cmake .. make ./xkb-switch #         ./xkb-switch -l #       ./xkb-switch -s ru #       (  ) 


Danach müssen Sie den build Ordner aus dem Projekt löschen oder löschen und den Quellcode in das Archiv packen, um das geänderte Projekt verwenden zu können. Es könnte so aussehen:



 cd ~/Projects/cpp/xkb-switch rm -rf ./build cd ~/Projects/cpp zip -r xkb-switch.zip xkb-switch 


Die Datei xkb-switch.zip dann zum Erstellen des Pakets verwendet werden.




Überprüfung beim Speichern des Projekts in Ihrem GitHub-Profil


Ich gehe davon aus, dass jeder, der diesen Abschnitt liest, zumindest ein wenig mit der Arbeit mit Git vertraut ist und bereits ein Profil auf GitHub erstellt hat . Ich denke, diese Methode ist die beste, daher impliziert der Rest des Artikels, dass sie verwendet wird, sofern nicht anders angegeben.


Zuerst müssen Sie das ursprüngliche Projekt in Ihren GitHub einteilen . Danach klonen wir wie in der vorherigen Methode das Projekt auf unseren Computer, jedoch aus unserem Repository (in meinem Fall lautet der Benutzername alexandersolovyov ):



 cd ~/Projects/cpp git clone https://github.com/alexandersolovyov/xkb-switch.git 


Um Änderungen hinzuzufügen, ist es besser, einen neuen Zweig zu verwenden. Auf Wunsch können dann verschiedene Versionen des Programms verwendet werden. Außerdem können dem Projektautor mithilfe von Pull-Requests Änderungen vorgeschlagen werden. Wenn Sie beispielsweise die Datei CMakeLists.txt ein wenig reparieren CMakeLists.txt , müssen Sie zuvor einen neuen Zweig erstellen mit:



 git branch cmake_corrections 


Nachdem die Änderungen vorgenommen, überprüft und dem Zweig hinzugefügt wurden (mit git commit -am " " ), können Sie Ihrem GitHub einen neuen Zweig hinzufügen:



 git push origin cmake_corrections 


Danach können Sie bei Bedarf eine Pull-Anfrage stellen.


Sie können einen Link zum ursprünglichen Repository erstellen:



 git remote add ierton https://github.com/ierton/xkb-switch.git 


Aktualisieren Sie anschließend den Hauptzweig Ihres Repositorys so, dass er mit dem Original übereinstimmt:



 git pull ierton master 


Der Programmcode, der dem korrigierten Zweig entspricht, kann beim Erstellen der Drehzahl verwendet werden. Dazu müssen Sie die Adresse des Archivs im Formular in der Spezifikationsdatei angeben:



 Source0: https://github.com/-/-/archive/---.zip 


Dies ist jedoch nicht der Fall, wie der specblog-Benutzer aufgefordert hat. Es ist besser, Ihre Änderungen in Form von Patches zu übermitteln. Dazu müssen Sie Patch-Dateien aus den Änderungen in Ihrem Zweig erstellen und in den ~/rpmbuild/SOURCES/ kopieren, um das Paket zu erstellen ( ~/rpmbuild/SOURCES/ ). Dann müssen Sie sie in der Spezifikationsdatei angeben. Wir werden dies etwas später betrachten, aber wenn Sie möchten, können Sie es hier lesen . Wenn Sie nicht wissen, wie man Patches erstellt, können Sie unter dem Spoiler nachsehen.




So erstellen Sie Patches mit git

Patches erstellen


Patches , sie sind Patches - dies sind Dateien, in denen Änderungen im Quellcode des Programms aufgezeichnet werden. Sie werden als Alternative zu den Befehlen git pull und git push für die Kommunikation zwischen lokalen Code-Repositorys verwendet, wenn es nicht bequem ist, Änderungen aus einem Remote-Repository abzurufen, oder wenn der Änderungsverlauf des Projekts und die Prinzipien der Arbeit damit so sind, dass es besser ist, Patches zu verwenden.



Stellen wir uns vor, wir müssen Änderungen an der Datei CMakeLists.txt . Zuerst müssen Sie alles wie oben beschrieben tun: Der Hauptzweig in unserem GitHub-Repository sollte dem Hauptzweig des ursprünglichen Projekts entsprechen, und für Ihre Änderungen müssen Sie den Zweig cmake_corrections verwenden . Dann müssen Sie zu diesem Zweig gehen, die erforderlichen Änderungen vornehmen und sie mithilfe von Commits in Git speichern.


Jetzt müssen Sie die Änderungen als Patch-Dateien im Ordner ~/rpmbuild/SOURCES (wenn Sie Rosa Linux nicht verwenden, kann der Pfad zum Ordner ~/rpmbuild/SOURCES unterschiedlich sein). Zum Beispiel dies (ich meine, wir befinden uns im Projektordner - zum Beispiel ~/Projects/cpp/xkb-switch - und im Zweig cmake_corrections ):


 git format-patch -o ~/rpmbuild/SOURCES origin/master 

Der Befehl git format-patch erstellt für jedes Commit eine git format-patch Datei. In diesem Formular werden Patches erstellt, die mit dem durch das letzte Argument angegebenen Commit beginnen und mit dem letzten Commit des aktuellen Zweigs enden. Sie können ein Commit auf folgende Weise angeben: am Anfang des Hashs mit dem HEAD- Zeiger oder dem Namen des Zweigs, der nun das gewünschte Commit angibt. Die Hauptsache ist, dass eines der Commits, die sichtbar sind, wenn das git log ausgeführt wird, als Start genommen wird. Das heißt, Sie können keine Patches aus einem Commit erstellen, das sich in einem anderen Zweig befindet.


Und Sie können sich erinnern (oder sehen), wie viele Commits wir vom Hauptzweig zurückverzweigt haben, und Patches für eine bestimmte Anzahl von Commits zurück erstellen. Wenn wir beispielsweise zwei Commits ausführen würden, wäre der Befehl:


 git format-patch -o ~/rpmbuild/SOURCES -2 

Hier wird die Anzahl der Commits mit -2 . Sie können anstelle dieser Zahl eine beliebige Anzahl von ihnen angeben.


Sie können den Bereich der Commits angeben, aus denen Patches erstellt werden sollen, indem Sie zwei Punkte zwischen die Links zu den anfänglichen und endgültigen Commits setzen:


 git format-patch -o ~/rpmbuild/SOURCES master..cmake_corrections 

Der Name jeder Patch-Datei besteht aus einer Seriennummer und der ersten Zeile eines Commit-Kommentars. Daher ist es besser, jede Datei umzubenennen, damit die Beschreibung des Patches kurz und klar sein Wesen beschreibt. Zum Beispiel so:


 mv 0001-Return-memory-allocated-by-XkbRf-getNamesProp()-for-tmp.patch 001-Fix-memory-leak.patch 

Die Namenskonvention für Patches im Artikel über die Syntax der Spezifikationsdatei empfiehlt, vor der Beschreibung jeder Patch-Datei package_name-version-rosa- hinzuzufügen. Möglicherweise empfiehlt sich dies, wenn Sie Patches per E-Mail senden, jedoch nicht zum Erstellen von Paketen. Wir erstellen Pakete auf unserem Computer. Es ist daher besser, den Ordner ~/rpmbuild/SOURCES jedes Mal zu leeren, bevor Sie ~/rpmbuild/SOURCES Paket mit einem anderen Programm oder einem neuen Versionspaket erstellen.


Wenn Sie nun den Haupt-Repository-Zweig ( Master ) so aktualisieren müssen, dass er mit dem Original übereinstimmt, muss der Änderungszweig ( cmake_corrections ) anschließend mit dem git rebase aktualisiert werden. Wie das geht, können Sie hier sehen . Danach müssen die Patches neu erstellt werden.





Bereiten Sie den "Arbeitsplatz" vor, um ein Paket zu erstellen


Zuerst müssen Sie eine Verzeichnisstruktur erstellen. Die gesamte Montage erfolgt im Ordner rpmbuild im rpmbuild Ordner des rpmbuild . Erstellen Sie die anfängliche Verzeichnisstruktur und wechseln Sie in den Ordner für die Spezifikationsdateien:



 mkdir -p ~/rpmbuild/SPECS && cd ~/rpmbuild/SPECS 


Für Rosa Linux reicht dies aus: Die verbleibenden Ordner werden automatisch erstellt.


Eine andere Distribution verwendet möglicherweise einen anderen Dateispeicherort, um das Paket zu erstellen. Möglicherweise müssen Sie die gesamte Ordnerhierarchie manuell erstellen. Suchen Sie nach Informationen für Ihre Distribution, wenn Sie Rosa Linux nicht verwenden. Dies könnte beispielsweise in Red Hat so aussehen .


Wenn das Paket mit Fehlern erstellt wurde, rpmbuild nicht alle mit dem Befehl rpmbuild erstellten Dateien gelöscht - genau wie bei einer erfolgreichen Erstellung. Wir werden viele Male versuchen, das Paket zu sammeln, und die nach dem letzten Mal verbleibenden Dateien werden stören. Daher ist es besser, ein einfaches Skript zu erstellen, mit dessen Hilfe sie schnell entfernt werden können. Erstellen Sie eine cleanup.sh-Datei und legen Sie sie im ~/rpmbuild/SPECS . Hier sind die Inhalte:



 !#/bin/sh rm -rf ~/rpmbuild/BUILD/* rm -rf ~/rpmbuild/BUILDROOT/* rm -rf ~/rpmbuild/RPMS/* rm -rf ~/rpmbuild/SRPMS/* 


Natürlich ist es besser, mit dem chmod u+x cleanup.sh Ausführungsrechte dafür chmod u+x cleanup.sh .


Wenn Sie ein Paket aus Dateien sammeln möchten, die sich auf dem lokalen Computer befinden - wenn Sie GitHub nicht verwenden und Änderungen an den Projektdateien vorgenommen haben oder wenn Sie ein Paket aus Ihrem eigenen Programm erstellen möchten, das nur auf Ihrem Computer gespeichert ist -, müssen Sie das Projekt in ein Archiv packen ( B. .zip , .tar oder .tar.gz ) und legen Sie es im Ordner SOURCES . Zum Beispiel so:



 cd ~/Projects/cpp/ zip -r xkb-switch.zip xkb-switch mkdir -p ~/rpmbuild/SOURCES cp xkb-switch.zip ~/rpmbuild/SOURCES/ 


Wenn Sie nach dem Erstellen des Programms eine andere oder dieselbe, aber unterschiedliche Version erstellen möchten, müssen Sie alle Dateien aus dem Ordner ~/rpmbuild/SOURCES löschen und anschließend Ihr Archiv dort kopieren (wenn Sie es nicht von GitHub herunterladen) und Patch-Dateien (falls verwendet). Andernfalls wird die Archivdatei höchstwahrscheinlich nicht von GitHub heruntergeladen (warum - siehe später), und es ist auch schwierig herauszufinden, welche Patch-Datei zu welchem ​​Programm gehört.




Beginnen wir mit der Erstellung einer Spezifikationsdatei


Die Basis für die Erstellung eines RPM-Pakets ist die sogenannte Speck-Datei . Diese Datei enthält die Anweisungen für das Programm rpmbuild (bzw. rpmbuild das zum rpmbuild des Pakets erforderlich ist.


Erstellen Sie die Datei xkb-switch.spec im ~/rpmbuild/SPECS/ . Der einfachste Weg, um zu beginnen, ist mit einer Vorlage, die auf der Website Template Spec Files zu finden ist.


Aus der README auf der xkb-switch- Projektseite ist bekannt, dass das Programm mit dem Dienstprogramm cmake kompiliert wird. Daher wählen wir die Spezifikationsdatei für ein mit CMake erstelltes Programm aus und kopieren die gesamte Vorlage in unsere Spezifikationsdatei. Um unser RPM-Paket richtig zusammenzustellen, muss diese Vorlage natürlich stark geändert werden, was wir auch tun werden.




Ein bisschen über die Syntax von Spezifikationsdateien


  • Mit der Syntax der Spezifikationsdatei können Sie Kommentare im Bash-Stil hinzufügen.
  • Sie können Leerzeichen als Leerzeichen zwischen den Werten in derselben Zeile verwenden, um das Erscheinungsbild gerader Spalten zu erstellen. In der Dokumentation wird jedoch dringend empfohlen, ein Tabulatorzeichen zu verwenden (ein oder zwei Zeichen, solange die Spalten gerade bleiben). Hinweis: In allen Codebeispielen in diesem Artikel werden nur Leerzeichen verwendet. Es ist daher besser, nicht den gesamten Text von hier in Ihre Spezifikationsdatei zu kopieren, sondern ihn selbst zu drucken.
  • Optionsfelder bestehen aus einem speziellen Optionsnamen mit einem Doppelpunkt und dem nächsten Wert über Tabulatoren (oder Leerzeichen). Der Fall von Zeichen in Feldnamen spielt keine Rolle. Zum Beispiel:
      Name: xkb-switch 

  • Wenn dem Wort das % -Symbol vorangestellt ist (z. B. %description ), ist dies ein spezielles Schlüsselwort. Dies kann ein Befehls-, Makro- oder Skriptaufruf sein. Danach können die verwendeten Parameter angegeben werden. Und es gibt Schlüsselwörter, die den Beginn eines Befehls- oder Optionsblocks angeben. Dann können Parameter daneben angegeben werden, und in den nächsten Zeilen sollten Befehle oder eine Liste von Optionen stehen, die ich im vorherigen Absatz beschrieben habe. Nach einem solchen Block sollte eine leere Zeile übrig bleiben.
  • Um den Wert einer Konstante zu verwenden, müssen Sie an einer %{_} eine Konstruktion der Form %{_} einfügen. Sein Wert kann vordefiniert sein oder durch eine Option (z. B. Name: xkb-switch ) oder mithilfe des Schlüsselworts %define . Alle diese Konstanten werden auch als Makros betrachtet. Ihre Verwendung wird nachstehend ausführlicher erörtert.



Spec-Datei-Header


In der Spezifikationsdatei wird der Header immer zuerst geschrieben. Dies ist eine Liste von Optionen, die für das Haupt-RPM-Paket gelten. Wenn das Paket fertig ist, werden fast alle diese Informationen angezeigt, wenn die Beschreibung angezeigt wird. Die einzelnen Zeilen geben Folgendes an:



Zusammenfassung:
Eine kurze Beschreibung des Pakets. Ich habe die Beschreibung in der Datei README.md im xkb-switch- Projekt ausspioniert: Query and change XKB layout state .

Name:
Der Name des Pakets. In unserem Fall ist dies ein xkb-switch .

Version:
Programmversion. Um dies herauszufinden, schauen Sie sich am besten die Datei CMakeLists.txt im Projektstammordner an. Natürlich müssen Sie die Datei aus der Kopie des Projekts entnehmen, das für die Montage verwendet wird. Wenn Sie das ursprüngliche Projekt verwenden, können Sie die Datei direkt auf der GitHub-Seite öffnen . Wie Sie sehen können, besteht die Version aus MAJOR_VERSION , MINOR_VERSION und RELEASE_VERSION . Ich habe das Programm Version 1.6.0 .

Veröffentlichung:
Die Versionsnummer des Pakets selbst. Zeigt an, wann ein Paket mit einem Programm derselben Version zusammengestellt wird. In unserem Fall ist dies "1", da noch nie jemand ein Programm dieser Version zusammengestellt hat. Wenn wir im Idealfall bereits versucht haben, das Paket zu erstellen und die Assembly das Ende erreicht hat (auch wenn Fehler aufgetreten sind), müssen Sie diese Zahl nach jedem neuen Versuch um 1 erhöhen und gleichzeitig die alten gesammelten Pakete nicht aus den rpmbuild/RPMS und rpmbuild/SRPMS : Als nächstes werden neue Pakete mit einer neuen Build-Nummer erstellt. Möglicherweise sollte dies durchgeführt werden, wenn Sie einen speziellen Server für die Montage verwenden. Wir benutzen unseren Computer und werden stattdessen die Ordner bereinigen. Wenn sich ein Paket mit einem Programm dieser Version bereits in den Repositorys der Linux-Distribution befindet, Sie jedoch mit anderen Einstellungen kompilieren, ist es besser, die Versionsnummer 1 höher als dieses Paket anzugeben.

Lizenz:
Der Kurzname der Lizenz, unter der das Programm vertrieben wird. Nach den Regeln von Rosa Linux können Sie nur Pakete mit einer Lizenz erstellen, die eine kostenlose Verteilung ermöglicht. Aus der Datei README.md können Sie README.md , dass die Lizenz GNU GPLv3 ist . Also schreiben wir: GPLv3+ .

Gruppe:
Die Gruppe oder Kategorie, zu der das Programm gehört. Mithilfe dieser Gruppen werden Programme im Anwendungsstartmenü und im Fensterprogramm-Manager („Software hinzufügen oder entfernen“) sortiert. Die Liste der Gruppen für Rosa Linux finden Sie hier . Ich denke, Development\X11 ist das Beste für uns, da das Programm mit X11 zusammenhängt und hauptsächlich zum Erstellen von Skripten und Plugins für Vim benötigt wird.

URL:
Internetadresse, unter der Sie den Originalquellcode des Programms herunterladen können. Dies wird beim Anzeigen von RPM-Paketinformationen angegeben. Dieser Artikel ist optional, wir geben jedoch Folgendes an: https://github.com/ierton/xkb-switch

Quelle0:
Der Name der Archivdatei, die den Quellcode enthält, oder die Internetadresse, unter der sie heruntergeladen werden kann. Wenn Sie im Internet eine Adresse angeben, wird die Datei beim ersten Erstellen nach ~/rpmbuild/SOURCES/ heruntergeladen. Wenn eine solche Datei bereits vorhanden ist, wird sie nicht mehr heruntergeladen, rpmbuild Programm rpmbuild nur den am Ende dieser URL angegebenen Dateinamen. Sie können nur den Dateinamen angeben, dieser muss jedoch manuell im Ordner ~/rpmbuild/SOURCES/ werden. Es ist besser, die Adresse Ihrer Kopie des Projekts auf GitHub anzugeben. Ich habe die Datei https://github.com/alexandersolovyov/xkb-switch/archive/master.zip . Sie können mehrere verschiedene Quellen angeben, um die Quellen aus mehreren Archiven mithilfe einer Speck-Datei zu sammeln. Im Namen der Option zum Hinzufügen jedes nachfolgenden Archivs sollte sich dann die Anzahl erhöhen ( Source1 , Source2 usw.). Diese Dateiadressen sind beim Anzeigen von RPM-Paketinformationen nicht sichtbar.

Patch0:
Diese Option befindet sich nicht in der Vorlagendatei. Dies kann nützlich sein, wenn Sie Ihre Änderungen in Form von Patches in die Projektdateien des Programms übertragen möchten. Bei der Option Source0 muss jede Datei in einer separaten Zeile angegeben werden, und die Zahl am Ende des Optionsnamens muss jedes Mal erhöht werden. Die Patch-Dateien sollten sich im Ordner ~/rpmbuild/SOURCES (neben dem heruntergeladenen ~/rpmbuild/SOURCES ) befinden. Der Name jeder Datei muss ohne Pfad dazu geschrieben werden. Es ist nicht erforderlich, alle Patch-Dateien hier anzugeben. Es können nur diejenigen verwendet werden, die Sie anwenden möchten.

BuildRequires:
Zum Erstellen des Programms erforderliche Pakete. Die Vorlage cmake . Die Datei CMakeLists.txt gibt an, dass die Mindestversion von CMake für die Assembly nicht niedriger als 2,6 sein sollte. cmake >= 2.6 Sie daher besser cmake >= 2.6 . Mit der separaten Option BuildRequires: können Sie weitere Pakete hinzufügen, die jeweils in einer separaten Zeile stehen. Die Liste der für die Assemblierung erforderlichen Pakete finden Sie, indem Sie die README des Projekts lesen und die Datei CMakeLists.txt (insbesondere die Funktionen FIND_PACKAGE , TARGET_LINK_LIBRARY , FIND_PROGRAM ) TARGET_LINK_LIBRARY FIND_PROGRAM . Dann müssen Sie den richtigen Paketnamen in den Repositorys mit dem Befehl urpmq -a __ . In unserem Fall enthält die Kompilierungseinstellungsdatei ( CMakeLists.txt ) bereits Zeilen, die prüfen, ob die erforderlichen Pakete im System vorhanden sind. Es ist jedoch besser, auch hier die gesamte Liste anzugeben:
 # CMake  2.6   BuildRequires: cmake >= 2.6 #  C/C++ BuildRequires: gcc #    libxkbfile BuildRequires: libxkbfile-devel #   X11   libxkbfile, #  libx11-devel   . #    man: BuildRequires: xz 


Benötigt :, Bietet:
Diese Optionen sind nicht im Beispiel enthalten, können aber manchmal nützlich sein. Sie stellen Abhängigkeiten zwischen Paketen her.Die Option Providesgibt die Funktionen an, die von dem zu erstellenden Paket bereitgestellt werden. Dies kann der Name der Sprachdatei - Header C oder Dynamic Link Library - Namen oder eine besondere Funktion. Eine Option Requiresgibt an, von der Gelegenheit andere Pakete abhängig Build - Pakete. Package Manager ( rpm, urpm, oder andere , die Distribution verwenden), wenn für Abhängigkeiten suchen , diese Suche nach Möglichkeiten eher als Paketname. Daher ist Provideses besser, die Version der bereitgestellten Opportunity anzugeben und für Requireswelche Versionen der bereitgestellten Opportunities geeignet sind. Die Version ist durch Zeichen gekennzeichnet >=,=oder <=von Räumen umgeben. Normalerweise werden zuerst alle Optionen angezeigt Requires, dann - Providesein Feature-Name pro Zeile - wie für BuildRequires:. In der Regel werden beim Erstellen von Paketen unter Rosa Linux Abhängigkeiten automatisch erkannt, und diese Optionen müssen selten angegeben werden.

AutoReq:, AutoProv:
Wenn Sie ein Programm auswählen , die in einer Sprache geschrieben ist , mit dem der Manager rpm neu sind, oder das ist proprietär und Abhängigkeiten werden nicht automatisch richtig definiert sind , können Sie die automatische Erkennung deaktivieren Opportunities (mit AutoProv: no) und / oder Abhängigkeit (mit Hilfe AutoReq: no).

% Beschreibung
Dieser Block ist nicht mehr Teil des Headers, sondern ihm zugeordnet. Er wird dem RPM-Paket eine vollständige Beschreibung des Programms hinzufügen. Danach sollte eine leere Zeile verbleiben. Die Beschreibung kann wie folgt sein:
 %description xkb-switch is a C++ program that allows to query and change the keyboard layout state for X11 Window System (XKB) via command line. It provides a command 'xkb-switch', and bindings for API of the Vim text editor via 'libxkbswitch.so'. It is mainly used by a plugin for Vim text editor, vim-xkbswitch. Originally ruby-based code written by J.Broomley. 




Zeilen aus der Vorlage beginnen mit %filesund %find_langwerden nur benötigt, wenn Sie eine Anwendung mit Unterstützung für mehrere Sprachen erstellen. Löschen Sie sie daher.


Weiter nach dem Trennlinienkommentar, gefolgt von Befehlen und Makros, die vor dem Packen der Dateien ausgefüllt werden müssen. Alle diese Befehle sind in Blöcke unterteilt, die mit speziellen Schlüsselwörtern definiert werden.




Quellenvorbereitung


Der erste ist ein Block %prep, der die Befehle angibt, die für die Kompilierung vorbereitet werden sollen. Darin befindet sich ein Makrobefehl %setup. Sie führt ein Skript aus, das Folgendes ausführt:



  • , SourceX: ( — Source0: ). , .
  • ~/rpmbuild/SOURCES/ .
  • ~/rpmbuild/BUILD/ .
  • .


-q , .


, %prep :



 rpmbuild -bp ~/rpmbuild/SPECS/xkb-switch.spec 


rpmbuild . , rpm : rpmbuild , . ( root sudo ). rpmbuild , man rpmbuild . , , , — , rpmbuild .


: xkb-switch-1.6.0: No such file or directory . , ~/rpmbuild/BUILD/xkb-switch-1.6.0 , .



 ls ~/rpmbuild/BUILD/ 


, xkb-switch-master . %setup -n . %prep - :



 %prep %setup -q -n xkb-switch-master 


~/rpmbuild/SPECS/cleanup.sh , BUILD , , %prep . , exit 0 . , .


, . %prep . , , :


 %apply_patches 

rpmbuild -bp xkb-switch.spec . — .


Maximum RPM .


.




Zusammenstellung


%build . README , cmake .. make , - . : , . , %build :



 ~/rpmbuild/SPECS/cleanup.sh rpmbuild -bc ~/rpmbuild/SPECS/xkb-switch.spec 


exit 0 : .


, . shell ( bash zsh, ). rpmbuild , . shell - — . ( .)


- , , , %build shell .


, , . cmake , , , %cmake - , , . ( — CMakeLists.txt ). , .




Installation


, . %install , , , ~/rpmbuild/BUILDROOT/__-buildroot/ .


__ , Name: -, ( Version: -), ( Release: -), , .


README , make install , build . - - %makeinstall_std -C build , . ( , ):



 ~/rpmbuild/SPECS/cleanup.sh rpmbuild -bi ~/rpmbuild/SPECS/xkb-switch.spec 


, RPM. - , .





, - . , ~/rpmbild/BUILDROOT/ . ( , , tree , - Linux.) , , .debug . , , : .


, , %files -. , , . .


%files -. , . Rosa Linux %prep ( - ). , , , , — . - (, , ).


%files , RPM. , :



 %files %{_bindir}/%{name} %{_libdir}/libxkbswitch.so %{_libdir}/libxkbswitch.so.1 %{_libdir}/libxkbswitch.so.%{version} %{_mandir}/man1/%{name}.1.xz 


-. , , /usr/lib/rpm/macros . , %{_bindir} , %{_libdir} — , %{_mandir} — man. %{name} %{version} Name: Version: -.


:



 ~/rpmbuild/SPECS/cleanup.sh rpmbuild -ba ~/rpmbuild/SPECS/xkb-switch.spec 


… 2 1 . rpmlint , . , , Rpmlint Errors , :


`xkb-switch.i586: E: Inkohärente-Version-im-Name (Badness: 50) 1`
Fehler: Die Version im Bibliothekspaketnamen ist nicht korrekt angegeben.

`xkb-switch.i586: E: ausführbares Paket in der Bibliothek (Badness: 1) / usr / bin / xkb-switch`
Fehler: Das Bibliothekspaket enthält eine ausführbare Datei.

`xkb-switch.i586: W: Entwicklungsdatei-in-Nicht-Entwicklungspaket / usr / lib / libxkbswitch.so`
Warnung, dass eine Entwicklungspaketdatei ( -devel) in einem Paket gefunden wurde, das nicht für die Entwicklung vorgesehen war.



Alles klar? Ich glaube nicht. Schauen wir uns genauer an, was hier passiert.




Was ist RPMLint?


Rosa Linux rpmbuild rpmlint , . rpmlint , , . , Rosa Linux ( , rpmlint ) .


, , . ~/rpmbuild/RPMS/_/ rpmlint -i __ .


Übrigens, wenn Sie ein vorgefertigtes RPM-Paket von der Website eines Projekts heruntergeladen haben, können Sie vor der Installation eines solchen Pakets mit demselben Befehl überprüfen, wie es für Rosa Linux korrekt erstellt wurde rpmlint -i __.




Arten von RPM-Paketen für Rosa Linux


Pakete für Rosa Linux sind in 6 Typen unterteilt. Im Idealfall sollte jedes zusammengebaute Paket nur einem dieser Typen entsprechen.


Ausführbares Paket
Es ist binär. Es enthält nur eine Binärdatei oder ein Skript, die direkt zur Ausführung bestimmt sind. Die Dateien dieser Pakete werden meistens in einem Ordner /bin/oder in installiert /usr/bin. Kann auch Links enthalten - für die Möglichkeit, das Programm unter verschiedenen Namen aufzurufen. Der Name des Pakets entspricht dem Namen des Programms. Solche Pakete sind oft bibliotheksabhängig.

Die Bibliothek
Es enthält kompilierte Dateien der dynamisch verbundenen ("gemeinsam genutzten", "gemeinsam genutzten") Bibliothek, die von Programmen verwendet wird. Normalerweise ist dies die Bibliotheksdatei selbst, deren Name mit der Version endet, und ein Link zu dieser Datei, deren Name mit der ersten Versionsnummer endet. Zum Beispiel kann die Bibliothek libxkbfile1.0.2 - Version wird es Datei , libxkbfile.so.1.0.2um es und Link libxkbfile.so.1. Der Name des Bibliothekspakets, anhand dessen es im Repository des Installationsprogramms erkannt wird, endet mit der ersten Versionsnummer und beginnt mit dem Präfix lib. Die Bibliothek hat den libxkbfilerichtigen Namen -libxkbfile1. Dies liegt an der Tatsache, dass sich die erste Versionsnummer normalerweise nur bei inkompatiblen Bibliotheksänderungen ändert. Daher können mehrere Pakete mit einer Bibliothek unterschiedlicher Versionen installiert werden, wenn einige Programme die alte Version der Bibliothek und andere eine neuere Version verwenden.

Paket für Entwickler
Dateien, die zum Kompilieren von Programmen erforderlich sind, die die Bibliothek verwenden, aber für die Arbeit vorgefertigter Programme nicht erforderlich sind. Bei einfachen C / C ++ - Programmen ist dies ein Link zur Bibliotheksdatei, jedoch ohne Versionen im Namen (zum Beispiel libxkbfile.so) sowie Header-Dateien (mit der Erweiterung .h). Name des Pakets endet mit -devel, zum Beispiel: libxkbfile-devel. Während der Installation hängt es immer von der entsprechenden Bibliothek ab. Zum Beispiel libxkbfile-develhängt das Paket von ablibxkbfile1.

Quellcode
Rosa Linux-Repositorys verfügen über RPM-Pakete, die den Quellcode für einige Programme enthalten - meist nur für diejenigen, die wirklich neu erstellt werden müssen . Die Namen dieser Pakete enden mit -srcoder -source(zum Beispiel apache-source). rpmbuilderstellt ein solches Paket immer automatisch und legt es ab ~/rpmbuild/SRPMS/.

Debugging-Symbole
Dies sind Informationen, die zum Debuggen eines fertigen Programms verwendet werden können. Es verknüpft Speicherorte in kompilierten Dateien mit dem Quellcode. Solche Pakete werden rpmbuildautomatisch vom Team erstellt , ihrem Namen wird eine Endung zugewiesen -debuginfo. Ich habe solche Pakete nicht in Rosa Linux-Repositorys gefunden.

Die Dokumentation
Rosa Linux-Repositorys enthalten Dokumentationspakete für verschiedene Programme und Bibliotheken. Ich kenne (vorerst) die Funktionen zum Erstellen solcher Pakete nicht. Ihre Namen in der Regel enden in doc: zum Beispiel libx11-doc, java-1.7.0-openjdk-javadoc. Übrigens sind fast alle im Stil von Websites erstellt. Um sie anzuzeigen, öffnen Sie am besten einen Browser, gehen Sie zur Adresse file:///usr/share/doc/und wählen Sie den gewünschten Ordner und die gewünschte Datei aus.




Unser Ergebnis


Jetzt ist alles klarer geworden.



  • Unser Paket xkb-switchenthält eine Datei libxkbswitch.so, die gemäß den Regeln in einem Paket für die Entwicklung enthalten sein muss . Daher gab eine Meldung , dass die Datei nicht in einem Paket für die Entwicklung zu entwickeln , ist: xkb-switch.i586: W: devel-file-in-non-devel-package /usr/lib/libxkbswitch.so.
  • , /usr/lib/libxkbswitch.so.1 /usr/lib/libxkbswitch.so.1.6.0 . , . : xkb-switch.i586: E: executable-in-library-package (Badness: 1) /usr/bin/xkb-switch .
  • , (1). : xkb-switch.i586: E: incoherent-version-in-name (Badness: 50) 1 .


, rpmlint , . . xkb-switch , libxkbswitch.so.1.6.0 , Vim . xkb-switch , C C++ . RPM- .


-:



- xkb-switch
 Summary: Query and change XKB layout state Name: xkb-switch Version: 1.6.0 Release: 1 License: GPLv3+ Group: Development/X11 URL: https://github.com/ierton/xkb-switch Source0: https://github.com/alexandersolovyov/xkb-switch/archive/master.zip BuildRequires: cmake >= 2.6 BuildRequires: gcc BuildRequires: libxkbfile-devel BuildRequires: xz %description xkb-switch is a C++ program that allows to query and change the keyboard layout state for X11 Window System (XKB) via command line. It provides a command 'xkb-switch', and bindings for API of the Vim text editor via 'libxkbswitch.so'. It is mainly used by a plugin for Vim text editor, vim-xkbswitch. Originally ruby-based code written by J.Broomley. %files %{_bindir}/%{name} %{_libdir}/libxkbswitch.so %{_libdir}/libxkbswitch.so.1 %{_libdir}/libxkbswitch.so.%{version} %{_mandir}/man1/%{name}.1.xz #------------------------------------------------------------------ %prep %setup -q -n xkb-switch-master %build %cmake %make %install %makeinstall_std -C build 





— , . , , xkb-switch 3 : , . :



  • /usr/bin/xkb-switch /usr/share/man/man1/xkb-switch.1.xz ,
  • /usr/lib/libxkbswitch.so.1 /usr/lib/libxkbswitch.so.1.6.0 ,
  • /usr/lib/libxkbswitch.so .


-. , ,
- Maximum RPM . - libxkbfile Rosa Linux .


.





- libxkbfile . - :



 %define major 1 %define libname %mklibname xkbswitch %{major} %define develname %mklibname -d xkbswitch 


%define . , ( ) — , . , %{major} 1 , .


%mklibname «lib», , — ( ). %{libname} «lib» + «xkbswitch» + ( %{major}) = libxkbswitch1 — .


-d %mklibname -devel . %{develname} libxkbswitch-devel — .





Version:



 Version: %{major}.6.0 


, -.


- . . :


 Name: xkb-switch Version: %{major}.6.0 Release: 1 Summary: Query and change XKB layout state License: GPLv3+ Group: Development/X11 URL: https://github.com/alexandersolovyov/xkb-switch Source0: https://github.com/alexandersolovyov/xkb-switch/archive/master.zip BuildRequires: cmake >= 2.6 BuildRequires: gcc BuildRequires: libxkbfile-devel BuildRequires: xz %description xkb-switch is a C++ program that allows to query and change the keyboard layout state for X11 Window System (XKB) via command line. It provides a command 'xkb-switch', and bindings for API of the Vim text editor, a library 'libxkbswitch'. It is mainly used for some plugins for Vim text editor, such as vim-xkbswitch. Originally ruby-based code written by J.Broomley. 




- . - , - ( rpm ). %package . -. , -. Version , Summary , Group . Provides Requires , . Name : , %package .


. %description — , %package .


Rosa Linux - %description -. libxkbswitch1 :


 %package -n %{libname} Version: %{version} Summary: A library for xkb-switch tool, provides API bindings for Vim text editor Group: Development/X11 %description -n %{libname} libxkbswitch library, required by xkb-switch tool. It provides bindings for API of the Vim text editor, which can be used via 'libxkbswitch.so.1'. 


-n %package %description , . - , xkb-switch-libxkbswitch1 . libxkbswitch1 . .


:


 %package -n %{develname} Version: %{version} Summary: Development library libxkbswitch, provides API bindings for Vim text editor Group: Development/X11 %description -n %{develname} Development files for libxkbswitch. Provides bindings for API of the Vim text editor via 'libxkbswitch.so'. 




, . %files .


, , %package , %description %files . , %description - . , , — xkb-switch .


- Rosa Linux %files , %prep . :


 %files %{_bindir}/%{name} %{_mandir}/%{name}.1.xz %files -n %{libname} %{_libdir}/libxkbswitch.so.%{major} %{_libdir}/libxkbswitch.so.%{version} %files -n %{develname} %{_libdir}/libxkbswitch.so 


, :



  • xkb-switch ~/usr/bin/xkb-switch ~/usr/share/man/man1/xkb-switch.1 ,
  • libxkbswitch1 ~/usr/lib/libxkbswitch.so.1 ~/usr/lib/libxkbswitch.so.1.6.0 ,
  • libxkbswitch-devel ~/usr/lib/libxkbswitch.so .


cleanup.sh rpmbuild -ba ~/rpmbuild/SPECS/xkb-switch.spec . 3 :



 libxkbswitch1.i586: W: no-documentation libxkbswitch-devel.i586: W: no-documentation libxkbswitch-devel.i586: W: no-dependency-on libxkbswitch/libxkbswitch-libs/liblibxkbswitch 


, . , . . Versuchen wir es herauszufinden.





, , , README.md . %files%doc :



 %doc README.md 


. %doc — . ~/rpmbuild/BUILD/xkb-switdh-master/README.md .


: libxkbswitch-devel.i586: W: no-dependency-on libxkbswitch/libxkbswitch-libs/liblibxkbswitch . , libxkbswitch-devel libxkbswitch .


rpm -qp -- . :


 [user@pc ~] $ cd ~/rpmbuild/RPMS/i586/ [user@pc ~/rpmbuild/RPMS/i586] $ ls libxkbswitch1-1.6.0-1-rosa2014.1.i586.rpm xkb-switch-1.6.0-1-rosa2014.1.i586.rpm libxkbswitch-devel-1.6.0-1-rosa2014.1.i586.rpm xkb-switch-debuginfo-1.6.0-1-rosa2014.1.i586.rpm [user@pc ~/rpmbuild/RPMS/i586] $ rpm -qp --provides libxkbswitch1-1.6.0-1-rosa2014.1.i586.rpm libxkbswitch.so.1 libxkbswitch1 = 1.6.0-1:2014.1 [user@pc ~/rpmbuild/RPMS/i586] $ rpm -qp --provides libxkbswitch-devel-1.6.0-1-rosa2014.1.i586.rpm devel(libxkbswitch) libxkbswitch-devel = 1.6.0-1:2014.1 [user@pc ~/rpmbuild/RPMS/i586] $ rpm -qp --requires libxkbswitch-devel-1.6.0-1-rosa2014.1.i586.rpm devel(libX11) devel(libgcc_s) devel(libstdc++) devel(libxkbfile) rpmlib(PayloadIsXz) <= 5.2-1 [user@pc ~/rpmbuild/RPMS/i586] $ rpm -qp --requires xkb-switch-1.6.0-1-rosa2014.1.i586.rpm libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1.3) libgcc_s.so.1 libgcc_s.so.1(GCC_3.0) libstdc++.so.6 libstdc++.so.6(CXXABI_1.3) libstdc++.so.6(GLIBCXX_3.4) libstdc++.so.6(GLIBCXX_3.4.11) libstdc++.so.6(GLIBCXX_3.4.20) libstdc++.so.6(GLIBCXX_3.4.9) libxkbswitch.so.1 rpmlib(PayloadIsXz) <= 5.2-1 


, libxkbswitch1 libxkbswitch.so.1 libxkbswitch1 . xkb-switch libxkbswitch.so.1 , libxkbswitch-devel libxkbswitch1 . , %package libxkbswitch-devel . :



 %package -n %{develname} Version: %{version} Summary: Development library libxkbswitch, provides API bindings for Vim text editor Group: Development/X11 Requires: %{libname} >= %{version} 


, … . libxkbswitch-devel , , . , , rpmbuild .


-, ( README.md ), — :



-
 %define major 1 %define libname %mklibname xkbswitch %{major} %define develname %mklibname -d xkbswitch # Main package. Automaticaly requires libxkbswitch and libxkbswitch-devel Name: xkb-switch Version: %{major}.6.0 Release: 1 Summary: Query and change XKB layout state License: GPLv3+ Group: Development/X11 URL: https://github.com/alexandersolovyov/xkb-switch Source0: https://github.com/alexandersolovyov/xkb-switch/archive/master.zip BuildRequires: cmake >= 2.6 BuildRequires: gcc BuildRequires: libxkbfile-devel BuildRequires: xz %description xkb-switch is a C++ program that allows to query and change the keyboard layout state for X11 Window System (XKB) via command line. It provides a command 'xkb-switch', and bindings for API of the Vim text editor, a library 'libxkbswitch'. It is mainly used for some plugins for Vim text editor, such as vim-xkbswitch. Originally ruby-based code written by J.Broomley. # libxkbswitch %package -n %{libname} Version: %{version} Summary: A library for xkb-switch tool, provides API bindings for Vim text editor Group: Development/X11 %description -n %{libname} libxkbswitch library, required by xkb-switch tool. It provides bindings for API of the Vim text editor, which can be used via 'libxkbswitch.so.1'. # libxkbswitch-devel %package -n %{develname} Version: %{version} Summary: Development library libxkbswitch, provides API bindings for Vim text editor Group: Development/X11 Requires: %{libname} >= %{version} %description -n %{develname} Development files for libxkbswitch. Provides bindings for API of the Vim text editor via 'libxkbswitch.so'. # xkb-switch %files %{_bindir}/%{name} %{_mandir}/man1/%{name}.1.xz # libxkbswitch1 %files -n %{libname} %{_libdir}/libxkbswitch.so.%{major} %{_libdir}/libxkbswitch.so.%{version} %doc README.md # libxkbswitch-devel %files -n %{develname} %{_libdir}/libxkbswitch.so %doc README.md #------------------------------------------------------------------ %prep %setup -q -n xkb-switch-master %build %cmake %make %install %makeinstall_std -C build 




Fazit


, RPM Rosa Linux ( ). , -. , — , , rpmrc , ABF , — .


— , -, - , — .








rpmbuild -bp specfile.spec
Run Training (% prep).

rpmbuild -bc specfile.spec
Run Kompilation (% build) und alle vorherigen Aktionen.

rpmbuild -bi specfile.spec
Run psevdoustanovku (% installieren) und alle vorherigen Aktionen.

rpmbuild -ba specfile.spec
Pakete vollständig erstellen .




Überprüfen Sie das fertige Paket


rpmlint -i package_file_name.rpm
Allgemeine Überprüfung - wie gut das Paket erstellt wurde.

rpm -qp --provides package_filename.rpm
Überprüfen Sie, welche "Funktionen" vom Paket bereitgestellt werden.

rpm -qp - Erfordert package_filename.rpm
Überprüfen Sie, von welchen "Funktionen" anderer Pakete dieses Paket abhängt.

rpm -qpl package_file_name.rpm
Liste der im Paket enthaltenen Dateien.

rpm -qpi package-file-name.rpm
Informationen zum Paket (aus dem "Header" der Spezifikationsdatei oder aus dem % package- Block ).



, p . , Rosa Linux, . urpmq , rpm -q . , urpmq -l _ , urpmq --requires _ .




( )


  1. Building RPMs — Quick Start — RPM Rosa Linux.
  2. RPM — , , . .
  3. RPM: spec — - Rosa Linux.
  4. Maximum RPMrpm RPM- RedHat Linux. , Rosa Linux. .
  5. Template Spec Files.spec . , -.
  6. Automatic Build Farm (ABF) — Rosa Linux. , , , .spec . -.
  7. Rpmlint Errors — , rpmlint .
  8. Packaging Group — Rosa Linux.
  9. Rosa Linux .
  10. Git —Git .

Source: https://habr.com/ru/post/de464993/


All Articles