👩‍❤️‍👩 💡 🧒🏿 Construire un package RPM pour Rosa Linux en pratique 🌃 🕷️ 🏪

Si vous utilisez le système d'exploitation Linux depuis longtemps et connaissez même un peu la programmation, vous devrez peut-être tôt ou tard compiler le programme à partir du code source. Peut-être que le programme souhaité ne sera pas dans les référentiels de distribution. Ou le programme a une ancienne version dans ces référentiels, et vous avez besoin de la dernière. Ou peut-être que vous avez créé un nouveau programme et que vous souhaitez le partager avec d'autres utilisateurs.

Bien sûr, vous pouvez installer le programme selon les instructions fournies avec le code source. Mais vous devrez ensuite gérer manuellement les fichiers du programme et surveiller ses dépendances. Il est préférable de créer un package avec le programme et d'utiliser le gestionnaire d'applications intégré au système d'exploitation.

J'espère que cet article vous aidera à comprendre rapidement comment créer un package RPM pour Rosa Linux ou une autre distribution qui utilise le gestionnaire de packages RPM (Mandriva, RedHat). Ou du moins, dites-moi où chercher des informations.

Ici, je vais montrer comment créer des packages RPM sur mon ordinateur local, en utilisant un exemple simple. Nous allons construire le programme xkb-switch dans le système d' exploitation Rosa Linux . Nous prendrons le code source du programme de GitHub .

L'article est divisé en plusieurs parties courtes, donc la table des matières est sous le spoiler

Table des matières

Un peu sur Rosa Linux

Rosa Linux est une distribution créée et supportée par des développeurs russes . Il est basé sur Mandriva , mais avec quelques fonctionnalités. J'utilise la version 32 bits de Rosa Fresh R8 , sortie en 2014. Maintenant, la version R8 n'est plus prise en charge par les développeurs (les référentiels ne sont pas mis à jour), mais cela fonctionne bien sur mon ordinateur portable, donc je ne veux pas installer une nouvelle version.

Rosa Fresh R8 Utilise le bureau KDE4 . Toutes les versions du package de distribution utilisent les gestionnaires rpm et urpm pour gérer les packages avec les applications, et les commandes correspondantes sont rpm , urpmi , urpme , urpmq , urpmf .

Les principes de construction de progiciels sont généralement rarement modifiés au sein de la même famille de distribution Linux. Par conséquent, ce qui est décrit dans cet article devrait fonctionner dans toutes les versions des distributions Rosa .

La construction de packages sur Rosa Linux est un peu plus simple que sur certaines autres distributions basées sur RPM . Certains points sont automatisés et n'ont pas besoin d'être configurés.

Un peu sur xkb-switch

J'ai aimé l'idée d'utiliser le plugin pour l'éditeur de texte Vim - xkbswitch , sur lequel il y a un article sur Habré . Il bascule automatiquement la disposition du clavier en anglais lorsque vous quittez le mode de saisie, et vice versa - à celui sur lequel le texte a été entré la dernière fois - si vous entrez à nouveau dans le mode de saisie. Pour que ce plugin fonctionne, vous avez besoin du programme xkb-switch , qui vous permet de changer la disposition du clavier à partir de la ligne de commande et des plugins pour l'éditeur Vim . Ce programme n'était pas dans les référentiels Rosa Linux R8 (et probablement personne ne l'ajoutera, car la distribution est déjà ancienne et le programme xkb-switch n'est pas très populaire).

Mise en place, finalisation, vérification du programme

Il est souvent nécessaire de configurer la compilation du programme pour qu'elle fonctionne correctement dans une distribution particulière ou même pour un système spécifique. Il arrive qu'un programme doive être construit avec d'autres options ou avec le support d'un pilote spécial. Ou peut-être voulez-vous corriger des erreurs dans le code du programme ou simplement vérifier si cela fonctionne. Pour ce faire, il est préférable de copier le code source sur votre ordinateur avant de créer le package RPM, essayez de le compiler et vérifiez le fonctionnement du programme compilé.

Si vous êtes sûr que vous n'aurez pas besoin de modifier les fichiers du projet, vous pouvez utiliser le code source d'origine sur le site Web du projet et procéder immédiatement à la création du package. Mais si vous devez modifier les paramètres de compilation, il est généralement beaucoup plus facile de modifier le fichier dans le dossier source (le soi-disant makefile ) que de traiter ensuite les options pour les commandes de compilation et le périphérique macro interne pour le fichier de spécifications.

Vérifier le code source sans votre profil sur GitHub

Si vous décidez de travailler avec le code source ou les paramètres de compilation du projet, mais que vous n'avez pas votre propre profil sur GitHub ou que vous ne souhaitez pas l'utiliser, vous pouvez simplement télécharger et décompresser le code source. Dans notre cas, cela pourrait ressembler à ceci (j'utilise le dossier ~/Projects/cpp pour le code source C ++ ):

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

Cela créera le dossier ~/Projects/cpp/xkb-switch contenant le code source. Bien sûr, au lieu d'utiliser git vous pouvez télécharger l'archive avec le programme et décompressez-la.

À partir du fichier README.md dans le dossier du projet, il est facile de deviner que l'utilitaire cmake est utilisé pour créer le programme. Par conséquent, si vous devez modifier les paramètres de compilation, dans notre cas, ils se trouvent dans le fichier CMakeLists.txt . Et nous essayons simplement de compiler le programme et de vérifier s'il fonctionne. Les commandes que vous devez utiliser pour cela sont écrites dans le même fichier README.md à la racine du projet.

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

Après cela, pour utiliser le projet modifié, vous devrez effacer ou supprimer le dossier de construction du projet et emballer le code source dans l'archive. Cela pourrait ressembler à ceci:

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

Le fichier xkb-switch.zip ensuite être utilisé pour construire le package.

Vérification avec enregistrement du projet dans votre profil GitHub

Je suppose que quiconque lit cette section est au moins un peu familier avec Git et a déjà configuré un profil sur GitHub . Je pense que cette méthode est la meilleure, donc le reste de l'article impliquera qu'elle est utilisée, sauf indication contraire.

Vous devez d'abord bifurquer le projet d'origine dans votre GitHub . Après cela, comme dans la méthode précédente, nous clonons le projet sur notre ordinateur, mais à partir de notre référentiel (dans mon cas, le nom d'utilisateur est alexandersolovyov ):

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

Pour ajouter des modifications, il est préférable d'utiliser une nouvelle branche. Ensuite, si vous le souhaitez, il sera possible d'utiliser différentes versions du programme. Et il sera également possible de proposer des modifications à l'auteur du projet à l'aide de pull-requests. Par exemple, si vous décidez de corriger un peu le fichier CMakeLists.txt , avant cela, vous devez créer une nouvelle branche avec:

 git branch cmake_corrections

Une fois les modifications effectuées, vérifiées et ajoutées à la branche (en utilisant git commit -am " " ), vous pouvez ajouter une nouvelle branche à votre GitHub:

 git push origin cmake_corrections

Après cela, vous pouvez faire une pull-request, si nécessaire.

Vous pouvez créer un lien vers le référentiel d'origine:

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

Et puis mettez à jour la branche principale de votre référentiel afin qu'elle corresponde à l'original:

 git pull ierton master

Le code de programme correspondant à la branche corrigée peut être utilisé lors de la construction du RPM. Pour ce faire, vous devrez spécifier l'adresse de l'archive sous la forme dans le fichier spec:

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

Mais, comme l'a demandé l'utilisateur de specblog , ce n'est en fait pas le cas. Il est préférable de transmettre vos modifications sous forme de correctifs. Pour ce faire, vous devez créer des fichiers de correctif à partir des modifications de votre branche et les copier dans le dossier source pour créer le package ( ~/rpmbuild/SOURCES/ ). Vous devrez ensuite les spécifier dans le fichier de spécifications. Nous y réfléchirons un peu plus tard, mais si vous le souhaitez, vous pouvez le lire ici . Si vous ne savez pas comment créer des patchs, vous pouvez regarder sous le spoiler.

Comment créer des correctifs à l'aide de git

Création de correctifs

Les correctifs , ce sont des correctifs - ce sont des fichiers dans lesquels les modifications sont enregistrées dans le code source du programme. Ils sont utilisés comme alternative aux commandes git pull et git push pour la communication entre les référentiels de code locaux s'il n'est pas pratique de «tirer» les modifications d'un référentiel distant, ou si l'historique des modifications du projet et les principes de travail avec lui sont tels qu'il est préférable d'utiliser des correctifs.

Imaginons que nous devons apporter des modifications au fichier CMakeLists.txt . Tout d'abord, vous devez tout faire comme décrit ci-dessus: la branche principale de notre référentiel GitHub doit correspondre à la branche principale du projet d'origine, et pour vos modifications, vous devez utiliser la branche cmake_corrections . Ensuite, vous devez aller dans cette branche, apporter les modifications nécessaires et les enregistrer dans git à l' aide de commits.

Vous devez maintenant enregistrer les modifications sous forme de fichiers correctifs dans le dossier ~/rpmbuild/SOURCES (si vous n'utilisez pas Rosa Linux, le chemin d'accès au dossier SOURCES peut être différent). Par exemple, ceci (je veux dire que nous sommes dans le dossier du projet - par exemple, ~/Projects/cpp/xkb-switch - et sur la branche cmake_corrections ):

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

La commande git format-patch crée un fichier de git format-patch pour chaque commit. Sous cette forme, il effectuera des correctifs à partir de la validation spécifiée par le dernier argument et se terminant par la dernière validation de la branche actuelle. Vous pouvez spécifier un commit de n'importe quelle manière: au début du hachage, en utilisant le pointeur HEAD ou le nom de la branche, qui indique maintenant le commit souhaité. L'essentiel est que l'un des commits visibles lorsque git log exécuté est pris comme début. Autrement dit, vous ne pouvez pas commencer à créer des correctifs à partir d'une validation qui se trouve dans une autre branche.

Et vous pouvez vous rappeler (ou voir) combien de validations nous avons ramifiées à partir de la branche principale, et faire des correctifs pour un certain nombre de validations. Par exemple, si nous avons fait deux commits, la commande serait:

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

Ici, le nombre de validations est défini à l'aide de -2 . Vous pouvez en spécifier n'importe quel nombre au lieu de cette figure.

Vous pouvez spécifier la plage de validations à partir de laquelle les correctifs doivent être effectués en plaçant deux points entre les liens vers les validations initiales et finales:

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

Le nom de chaque fichier de correctif se compose d'un numéro de série et de la première ligne d'un commentaire de validation. Par conséquent, il est préférable de renommer chaque fichier afin que la description du correctif décrive plus brièvement et clairement son essence. Par exemple, comme ceci:

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

la convention de dénomination des correctifs dans l'article sur la syntaxe du fichier spec recommande d'ajouter package_name-version-rosa- avant la description de chaque fichier patch. C'est peut-être une bonne pratique si vous envoyez des correctifs par e-mail, mais pas pour la construction de packages. Nous créons des packages sur notre ordinateur, il est donc préférable de vider le dossier ~/rpmbuild/SOURCES chaque fois avant de ~/rpmbuild/SOURCES package avec un autre programme ou un nouveau package de version.

Maintenant, si vous devez mettre à jour la branche du référentiel principal ( maître ) pour qu'elle corresponde à l'original, alors la branche de changement ( cmake_corrections ) devra être mise à jour à l'aide de la git rebase . Vous pouvez voir comment procéder ici . Après cela, les correctifs devront être recréés.

Préparer le "lieu de travail" pour créer un package

Vous devez d'abord créer une structure de répertoires. Tout l'assemblage a lieu dans le dossier rpmbuild dossier de départ de l' rpmbuild . Créez la structure de répertoires initiale et accédez au dossier des fichiers de spécifications:

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

Pour Rosa Linux, cela suffit: les dossiers restants seront créés automatiquement.

Une autre distribution peut utiliser un emplacement de fichier différent pour créer le package. Et vous devrez peut-être créer manuellement la hiérarchie complète des dossiers. Recherchez des informations pour votre distribution si vous n'utilisez pas Rosa Linux. Par exemple, cela pourrait ressembler à ceci dans Red Hat .

Si le package a été rpmbuild avec des erreurs, tous les fichiers créés par la commande rpmbuild ne rpmbuild pas supprimés - comme pour une génération réussie. Nous essaierons de récupérer le paquet plusieurs fois, et les fichiers restants après la dernière fois vont interférer. Par conséquent, il est préférable de créer un script simple qui vous aidera à les supprimer rapidement. Créez un fichier cleanup.sh et placez-le dans le ~/rpmbuild/SPECS . Voici son contenu:

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

Bien sûr, il est préférable de lui ajouter des droits d'exécution à l'aide de la commande chmod u+x cleanup.sh .

Si vous souhaitez collecter un package à partir de fichiers qui se trouvent sur l'ordinateur local - si vous n'utilisez pas GitHub et avez apporté des modifications aux fichiers de projet, ou si vous souhaitez créer un package à partir de votre propre programme qui est stocké uniquement sur votre ordinateur - vous devez compresser le projet dans une archive ( par exemple .zip , .tar ou .tar.gz ) et placez-le dans le dossier SOURCES . Par exemple, comme ceci:

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

Si, après avoir construit le programme, vous souhaitez en créer une autre ou la même, mais une version différente, vous devrez supprimer tous les fichiers du dossier ~/rpmbuild/SOURCES , puis copiez-y vos archives (si vous ne les téléchargez pas depuis GitHub ) et fichiers de correctifs (si utilisés). Sinon, le fichier d'archive ne sera probablement pas téléchargé depuis GitHub (pourquoi - voir plus tard), et il sera également difficile de déterminer quel fichier de correctif appartient à quel programme.

Commençons par créer un fichier de spécifications

La base pour construire un package RPM est le soi-disant fichier speck . Ce fichier contient les instructions du programme rpmbuild (ou plutôt rpm ) nécessaires à la construction du package.

Créez le fichier xkb-switch.spec dans le dossier ~/rpmbuild/SPECS/ . La façon la plus simple de commencer est d'utiliser un modèle disponible sur le site Web des fichiers de spécifications de modèle .

À partir du README sur la page du projet xkb-switch , il est connu que le programme est compilé à l'aide de l'utilitaire cmake . Par conséquent, nous allons sélectionner le fichier de spécifications pour un programme créé à l'aide de CMake et copier le modèle entier dans notre fichier de spécifications. Bien sûr, afin d'assembler correctement notre package RPM, ce modèle doit être beaucoup changé, ce que nous ferons.

Un peu sur la syntaxe du fichier spec

La syntaxe du fichier de spécifications vous permet d'ajouter des commentaires de style bash.
Vous pouvez utiliser des espaces comme espaces entre les valeurs sur la même ligne pour créer l'apparence de colonnes paires, mais la documentation recommande fortement d'utiliser le caractère de tabulation (un ou deux tant que les colonnes sont paires). Remarque: dans tous les exemples de code de cet article, seuls les espaces sont utilisés, il est donc préférable de ne pas copier tout le texte d'ici dans votre fichier de spécifications, mais de l'imprimer vous-même.
Les champs d'option se composent d'un nom d'option spécial avec deux points et la valeur suivante via des tabulations (ou des espaces). La casse des caractères dans les noms de champ n'a pas d'importance. Par exemple:
```
  Name: xkb-switch 
```
Si le mot est précédé du symbole % (par exemple, %description ), il s'agit d'un mot-clé spécial. Il peut s'agir d'une commande, d'une macro ou d'un appel de script. Ensuite, les paramètres qu'il utilise peuvent être indiqués. Et il y a des mots clés qui indiquent le début d'un bloc de commandes ou d'options. Ensuite, les paramètres peuvent être indiqués à côté, et sur les lignes suivantes, il devrait y avoir des commandes ou une liste d'options que j'ai décrites dans le paragraphe précédent. Après un tel bloc, une ligne vide doit être laissée.
Pour utiliser la valeur d'une constante, vous devez insérer une construction de la forme %{_} . Sa valeur peut être prédéfinie ou elle peut être déterminée par une option (par exemple, Name: xkb-switch ) ou en utilisant le mot clé %define . Toutes ces constantes sont également considérées comme des macros. Leur utilisation sera discutée plus en détail ci-dessous.

En-tête de fichier de spécifications

Dans le fichier de spécifications, l'en-tête est toujours écrit en premier. Il s'agit d'une liste d'options qui s'appliquent au package RPM principal. Lorsque le package est prêt, presque toutes ces informations seront affichées lors de la visualisation de sa description. Voici ce que les lignes individuelles indiquent:

Résumé:
Une brève description du package. J'ai espionné la description dans le fichier README.md dans le projet xkb-switch : Query and change XKB layout state .

Nom:
Le nom du package. Dans notre cas, c'est xkb-switch .

Version:
Version du programme. Pour le savoir, il est préférable de regarder le fichier CMakeLists.txt dans le dossier racine du projet. Bien sûr, vous devez extraire le fichier de la copie du projet qui sera utilisé pour l'assemblage. Si vous utilisez le projet d'origine, vous pouvez ouvrir le fichier directement sur sa page GitHub . Comme vous pouvez le voir, la version est composée de MAJOR_VERSION , MINOR_VERSION et RELEASE_VERSION . J'ai utilisé la version 1.6.0 du programme.

Communiqué:
Le numéro de version du package lui-même. Affiche l'heure à laquelle un package avec un programme de la même version est assemblé. Dans notre cas, c'est «1», car personne n'a jamais assemblé de programme de cette version. Dans le cas idéal, si nous avons déjà essayé de compiler le package et que l'assemblage a atteint la fin (même s'il y avait des erreurs), après chaque nouvelle tentative, vous devez augmenter ce nombre de 1 et en même temps ne pas supprimer les anciens packages assemblés des rpmbuild/RPMS et rpmbuild/SRPMS : Ensuite, de nouveaux packages avec un nouveau numéro de build seront créés. Peut-être que cela devrait être fait si vous utilisez un serveur spécial pour l'assemblage. Nous utilisons notre ordinateur et à la place nous nettoierons les dossiers. Si un package avec un programme de cette version est déjà dans les référentiels de la distribution Linux, mais que vous compilez avec d'autres paramètres, il est préférable de spécifier le numéro de version 1 de plus que ce package.

Licence:
Nom abrégé de la licence sous laquelle le programme est distribué. Selon les règles de Rosa Linux, vous ne pouvez créer des packages qu'avec une licence qui permet une distribution gratuite. README.md pouvez découvrir dans le fichier README.md que la licence est GNU GPLv3 . Nous écrivons donc: GPLv3+ .

Groupe:
Groupe ou catégorie auquel appartient le programme. À l'aide de ces groupes, les programmes sont triés dans le menu de lancement de l'application et dans le gestionnaire de programmes de la fenêtre («Ajouter ou supprimer des programmes»). La liste des groupes pour Rosa Linux peut être trouvée ici . Je pense que Development\X11 est le meilleur pour nous, car le programme est lié à X11 et est principalement nécessaire pour créer des scripts et des plugins pour Vim.

URL:
Adresse Internet où vous pouvez télécharger le code source d'origine du programme. Il sera spécifié lors de l'affichage des informations sur le package RPM. Cet article est facultatif, mais nous indiquerons: https://github.com/ierton/xkb-switch

Source0:
Le nom du fichier d'archive contenant le code source ou l'adresse Internet où il peut être téléchargé. Si vous spécifiez une adresse sur Internet, lors du premier build, le fichier sera téléchargé dans ~/rpmbuild/SOURCES/ . Si un tel fichier existe déjà, il ne sera plus téléchargé, c'est-à-dire que le programme rpmbuild n'utilisera que le nom de fichier spécifié à la fin de cette URL. Vous pouvez spécifier uniquement le nom du fichier, mais il devra ensuite être placé manuellement dans le dossier ~/rpmbuild/SOURCES/ . Il est préférable de fournir l'adresse de votre copie du projet sur GitHub. J'ai utilisé le fichier https://github.com/alexandersolovyov/xkb-switch/archive/master.zip . Vous pouvez spécifier plusieurs sources différentes pour collecter les sources de plusieurs archives à l'aide d'un fichier speck. Ensuite, au nom de l'option pour ajouter chaque archive suivante, le nombre doit augmenter ( Source1 , Source2 , etc.). Ces adresses de fichiers ne sont pas visibles lors de l'affichage des informations sur les packages RPM.

Patch0:
Cette option n'est pas dans le fichier modèle. Cela peut être utile si vous décidez de transférer vos modifications dans les fichiers de projet du programme sous forme de correctifs. Quant à l'option Source0 , chaque fichier doit être indiqué sur une ligne distincte et le nombre à la fin du nom de l'option doit augmenter à chaque fois. Les fichiers de correctifs doivent se trouver dans le dossier ~/rpmbuild/SOURCES (à côté de l'archive source téléchargée). Le nom de chaque fichier doit être écrit sans chemin d'accès. Il n'est pas nécessaire de spécifier tous les fichiers de patch ici - seuls ceux que vous souhaitez appliquer peuvent être utilisés.

BuildRequires:
Paquets requis pour construire le programme. Le modèle cmake . Le fichier CMakeLists.txt indique que la version minimale de CMake pour l'assemblage ne doit pas être inférieure à 2.6 , il est donc préférable de spécifier cmake >= 2.6 . Vous pouvez ajouter d'autres packages, chacun d'eux sur une ligne distincte, en utilisant l'option BuildRequires: séparée. La liste des packages nécessaires à l'assemblage peut être trouvée en lisant le README du projet et en examinant attentivement le fichier CMakeLists.txt (en particulier les fonctions FIND_PACKAGE , TARGET_LINK_LIBRARY , FIND_PROGRAM ). Ensuite, vous devez trouver le nom de package correct dans les référentiels à l'aide de la commande urpmq -a __ . Dans notre cas, le fichier de paramètres de compilation ( CMakeLists.txt ) contient déjà des lignes qui vérifient la présence des packages nécessaires dans le système. Mais il vaut mieux spécifier la liste entière ici aussi:

 # CMake  2.6   BuildRequires: cmake >= 2.6 #  C/C++ BuildRequires: gcc #    libxkbfile BuildRequires: libxkbfile-devel #   X11   libxkbfile, #  libx11-devel   . #    man: BuildRequires: xz

Nécessite:, Fournit:
Ces options ne sont pas dans l'échantillon, mais parfois elles peuvent être utiles. Ils établissent des dépendances entre les packages.L'option Providesspécifie les fonctionnalités fournies par le package en cours de construction. Cela peut être le nom de l' en- tête fichier de langue C , ou le nom de la bibliothèque de liens dynamiques, ou une fonction spéciale. Et l'option Requiresindique de quelles capacités d' autres packages dépendent le package. Package Manager ( rpm, urpmou d' autres qui utilisent votre distribution), lors de la recherche des dépendances à la recherche de ces opportunités plutôt que des noms de paquet. Par conséquent, Providesil est préférable d'indiquer la version de l' opportunité fournie et pour Requiresquelles versions des opportunités fournies conviennent. La version est indiquée par des signes >=,=, ou <=, entouré d'espaces. Habituellement, toutes les options sont indiquées en premier Requires, puis - Provides, un nom de fonction par ligne - le même que pour BuildRequires:. En règle générale, lors de la création de packages sur Rosa Linux, les dépendances sont automatiquement reconnues et ces options doivent rarement être spécifiées.

AutoReq:, AutoProv:
si vous créez un programme écrit dans une langue que le gestionnaire rpm est nouveau ou propriétaire et si les dépendances ne sont pas correctement détectées automatiquement, vous pouvez désactiver la détection automatique des capacités (avec AutoProv: no) et / ou des dépendances (avec aide AutoReq: no).

% description
Ce bloc ne fait plus partie de l'en-tête, mais lui est associé. Il ajoutera une description complète du programme au package RPM. Une ligne vide doit être laissée après. La description peut être la suivante:

 %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.

Les lignes du modèle commençant par %fileset ne %find_langsont nécessaires que si vous créez une application prenant en charge plusieurs langues, supprimez-les.

De plus, après le commentaire sur la ligne de division, suivi des commandes et des macros qui doivent être terminées avant de compresser les fichiers. Toutes ces commandes sont divisées en blocs définis à l'aide de mots clés spéciaux.

Préparation de la source

Le premier est un bloc %prepqui indique les commandes pour préparer la compilation. Il contient une macro-commande %setup. Elle exécute un script qui fait ce qui suit:

, 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 .

%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 ). , .

L'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: incoherent-version-in-name (Badness: 50) 1`
Erreur: La version dans le nom du package de bibliothèque n'est pas spécifiée correctement.

`xkb-switch.i586: E: exécutable-dans-bibliothèque-package (Badness: 1) / usr / bin / xkb-switch`
Erreur: le package de bibliothèque contient un fichier exécutable.

`xkb-switch.i586: W: fichier-devel-in-non-devel-package / usr / lib / libxkbswitch.so`
Avertissement qu'un fichier de package de développement ( -devel) a été trouvé dans un package qui n'était pas destiné au développement.

Tout est-il clair? Je ne pense pas. Examinons de plus près ce qui se passe ici.

Qu'est-ce que rpmlint

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

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

, RPM - , , , , Rosa Linux, rpmlint -i __ .

RPM Rosa Linux

Rosa Linux 6 . , .

Paquet exécutable
Il est binaire. Il ne contient qu'un fichier ou script binaire destiné directement à l'exécution. Les fichiers de ces packages sont le plus souvent installés dans un dossier /bin/ou dans /usr/bin. Peut également contenir des liens - pour la possibilité d'appeler le programme en utilisant plusieurs noms différents. Le nom du package correspond au nom du programme. Ces packages dépendent souvent de la bibliothèque.

Bibliothèque
Contient des fichiers compilés de bibliothèques connectées dynamiquement ("partagées", "partagées") utilisées par les programmes. Il s'agit généralement du fichier de bibliothèque lui-même, dont le nom se termine par la version, et d'un lien vers ce fichier, dont le nom se termine par le premier numéro de version. Par exemple, pour une bibliothèque libxkbfileversion 1.0.2, ce sera un fichier libxkbfile.so.1.0.2et un lien vers celui-ci,libxkbfile.so.1. Le nom même du package de bibliothèque, par lequel il est reconnu dans le référentiel du programme d'installation, se termine par le premier numéro de version et commence par le préfixe lib. La bibliothèque a le libxkbfilenom correct - libxkbfile1. Cela est dû au fait que le premier numéro de version ne change généralement qu'avec des modifications de bibliothèque incompatibles, et il sera donc possible d'installer plusieurs packages avec une bibliothèque de versions différentes si certains programmes utilisent l'ancienne version de la bibliothèque et d'autres utilisent une version plus récente.

Package pour développeurs
Fichiers nécessaires à la compilation de programmes utilisant la bibliothèque, mais inutiles pour le travail de programmes prêts à l'emploi. Pour les programmes C / C ++ simples , il s'agit d'un lien vers le fichier de bibliothèque, mais sans versions dans le nom (par exemple,libxkbfile.so), ainsi que les fichiers d'en-tête (avec l'extension .h). Nom du package se termine par -devel, par exemple: libxkbfile-devel. Lors de l'installation, cela dépend toujours de la bibliothèque appropriée. Par exemple, le package libxkbfile-develdépend libxkbfile1.

Code source
Les référentiels Rosa Linux ont des packages RPM contenant le code source de certains programmes - principalement ceux qui ont vraiment besoin d'être reconstruits. Les noms de ces packages se terminent par -srcou -source(par exemple, apache-source). rpmbuildcrée toujours un tel package automatiquement et le place ~/rpmbuild/SRPMS/.

Symboles de débogage
Il s'agit d'informations qui peuvent être utilisées pour déboguer un programme terminé. Il associe les emplacements des fichiers compilés au code source. Ces packages sont rpmbuildautomatiquement créés par l'équipe , une fin est attribuée à leur nom -debuginfo. Je n'ai pas trouvé de tels packages dans les référentiels Rosa Linux.

Documentation
Les référentiels Rosa Linux ont des packages de documentation pour divers programmes et bibliothèques. Je (pour l'instant) ne connais pas les caractéristiques de la construction de tels packages. Leurs noms se terminent généralement par doc: par exemple libx11-doc, java-1.7.0-openjdk-javadoc. Soit dit en passant, presque tous sont créés dans le style de sites Web, et pour les afficher, il est préférable d'ouvrir un navigateur, d'aller à l'adresse file:///usr/share/doc/et de sélectionner le dossier et le fichier souhaités.

Notre résultat

Maintenant, tout est devenu plus clair.

xkb-switch libxkbswitch.so , , , . , : 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

, . , . . Essayons de le comprendre.

, , , 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

Conclusion

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

— , -, - , — .

rpmbuild -bp specfile.spec
Exécuter la préparation (% prep).

rpmbuild -bc specfile.spec
Run compilation (build%) et toutes les actions précédentes.

rpmbuild -bi specfile.spec
Effectue une pseudo- installation (% install) et toutes les étapes précédentes.

rpmbuild -ba specfile.spec
Générez des packages complètement.

Vérification du colis fini

rpmlint -i package_file_name.rpm Vérification
générale - dans quelle mesure le package a été construit.

rpm -qp --provides package_filename.rpm
Vérifiez quelles "fonctionnalités" sont fournies par le package.

rpm -qp --requires package_filename.rpm
Vérifiez les "capacités" des autres packages dont dépend ce package.

rpm -qpl package_file_name.rpm
Liste des fichiers contenus dans le package.

rpm -qpi nom-fichier-package.rpm
Informations sur le package (à partir de "l'en-tête" du fichier de spécifications ou du bloc % package ).

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

( )

Building RPMs — Quick Start — RPM Rosa Linux.
RPM — , , . .
RPM: spec — - Rosa Linux.
Maximum RPM — rpm RPM- RedHat Linux. , Rosa Linux. .
Template Spec Files — .spec . , -.
Automatic Build Farm (ABF) — Rosa Linux. , , , .spec . -.
Rpmlint Errors — , rpmlint .
Packaging Group — Rosa Linux.
Rosa Linux .
Git — — Git .

Construire un package RPM pour Rosa Linux en pratique