Païou : Mandriva Linux depuis 2002. Aujourd'hui, c'est Mageia Linux
On se lasse de tout, sauf de comprendre.
Attribué à Virgile.
27 mars 2015 : Création de cette page.
Pour : linuxien averti.
Comme moi, vous pouvez être amenés à modifier un fichier .spec ou à en créer un nouveau.
Cette page ne décrira probablement pas tous les cas de figure. Puisse-t-elle simplement vous guider.
Elle va essayer de décrire ce qui peut se trouver dans un fichier .spec.
Ce fichier définit :
Cette page ne peut pas recenser tous les cas de figure possibles d'un fichier .spec. Vous pourrez compléter ces informations en étudiant bon nombre de fichiers spec.
Des remarques préliminaires :
Il comprend différents renseignements relatifs au paquetage :
Name: gzip le nom du paquetage
Summary: The GNU data compression program description brève
Version: 1.6
Release: %mkrel 7
URL: http://www.gnu.org/software/gzip/
License: GPLv3+
Group: Archiving/Compression
Il peut y avoir un champ
BuildArch: noarch lorsque le paquetage n'est pas spécifique à une architecture (doc, scripts bash , perl ...)
Les renseignements ci-dessus peuvent également être fournis au moyen de macros (l'intérêt des macros est qu'il suffit de définir la valeur une seule fois, au début du fichier) :
%define name gzip
%define version 1.6
%define release %mkrel 7
et plus loin :
name: %{name}
version: %{version}
release: %{release}
%define : Elle définit une constante utilisable par les sections suivantes du fichier.spec, constante qui est alors utilisée avec %{name}, %{version} ...
La valeur de cette constante peut être une chaîne de caractères ou une valeur booléenne (0/1).
%mkrel : macro qui est utilisée pour ajouter le suffixe défini dans le fichier .rpmmacros et la version de la distribution (ici 7) après le numéro de révision du paquetage.
%{name} : correspond à la valeur de variable name définie par %define
Il est possible d'inclure des conditions dans la construction des paquetages : inclure ou non des fonctions, des options de compilation ...
Un peu comme pour le bash ou d'autres langages, ce sont des constructions de la forme :
%if condition
Instructions
%else
Autres instructions
%endif
%Description marque le début du paragraphe qui décrit de façon plus détaillée le paquetage.
Tout ce qui vient après l'étiquette %Description, jusqu'à l'étiquette suivante, constitue la description du paquetage.
Il ne faut pas hésiter à bien documenter.
On peut y indenter des paragraphes, séparer avec des lignes vides ...
Pour construire le paquetage il est nécessaire de savoir où trouver les sources du logiciel d'origine. Un même paquetage peut nécessiter plusieurs logiciels différents et donc plusieurs sources.
Source0: ftp://ftp.gnu.org/gnu/gzip/gzip-%{version}.tar.xz(on utilise ici %version pour définir la version)
Source1: ftp://ftp.gnu.org/gnu/gzip/gzip-%{version}.tar.xz.sig
Le logiciel d'origine doit parfois être corrigé ou adapté. On utilise, pour ceci, des patchs. Ils doivent également être définis. Il peut y en avoir plusieurs.
Patch0: gzip-1.3.12-openbsd-owl-tmp.patch
Patch18: gzip-1.6-zgrep_signal_race_condition.patch
Pour pouvoir construire le nouveau paquetage, il faut que les outils appropriés soient disponibles.
BuildRequires: texinfo (le paquetage texinfo doit être installé).
De même, pour pouvoir installer le nouveau paquetage, par la suite, des dépendances doivent être installées.
Requires: mktemp less
Dans certains cas, le paquetage créé doit également fournir le nom d'un paquetage virtuel, c'est-à-dire qu'il fournit une fonctionnalité définie par ce nom.
Provides: xxxx
Le nouveau paquetage peut entrer en conflit avec d'autres, souvent plus anciens.
Conflicts: yyyy
Certains paquetages ne sont pas spécifiques à une architecture donnée. Ils sont notés noarch.
BuildArch: noarch
Maintenant que la présentation est terminée, la construction commence effectivement.
Depuis cette section %prep et jusqu'à la fin du fichier, à l'intérieur de chaque section, il faut considérer les instructions comme étant des instructions de script bash qui exécutent ce que rpmbuild doit faire durant les phases de construction, d'installation, de nettoyage.
Cette section prépare l'environnement de construction à l'aide de commandes sh et de scripts pré-définis. Une connaissance basique de bash est donc nécessaire.
Elle comprend le premier script pré-défini exécuté par rpmbuild : %prep.
En effet, %Prep marque le début de la section, mais est également un script %prep.
Le rôle du script est de :
Le script %prep peut avoir une option %prep -q pour devenir silencieux.
Pour terminer la préparation, il existe trois macros très utiles :
Cette macro se place directement après %prep. Elle
Il peut arriver que l'archive ne soit pas réalisée selon la forme classique : un répertoire conteneur se nommant nom_du_paquetage-sa_version, Ex gzip-1.6
Dans ce cas il faut ajouter une option à %setup.
Il se peut également qu'il y ait plusieurs sources à désarchiver. Il faut alors également ajouter les options adéquates.
Si vous avez des problèmes, je vous conseille de ne pas utiliser l'option q, dans un premier temps.
Elle applique un patch
%patch# : applique le patch numéro #
Le principal argument est : -p#. Il indique dans quel sous-répertoire de BUILD se trouve le fichier à patcher.
Par défaut, p=0 et cela correspond au répertoire de travail, c'est-à-dire le premier sous-répertoire de BUILD.
Si le patch est compressé, %patch va le décompresser automatiquement.
Cette macro remplace toutes les lignes %patch# -p1. Cela peut réduire le nombre de lignes du fichier spec.
Cette section contient le script qui compile réellement le logiciel. Il se compose de commandes lancées sur l'arborescence des sources décompressés : BUILD.
Quelques paquetages n'ont pas de sources devant être compilées. Ce sont alors des nonarch. La section reste alors vide et il n'y a que la ligne %Build ou %build
Cependant, avec la plupart des paquetages, il y a une phase de compilation.
Le type de compilation dépend de la façon dont a été écrit le programme source : il faut chercher la présence de fichiers README et INSTALL dans l'archive. Ils renseignent généralement sur la façon de procéder.
De plus en plus d'applications utilisent les outils autoconf et automake pour créer les scripts configure et make qui sont utilisés lors de la compilation.
Dans ce cas, la compilation est assez simple :
%configure2_5x
%make
Cette macro réalise la première phase de la compilation.
%configure2_5x détecte automatiquement les spécificités de votre machine et génère un fichier configure avec plusieurs options adéquates. Elle lance ce ./configure avec ses options.
Ce programme ./configure génère alors un fichier Makefile, exécuté ensuite avec une commande make.
Faites rpm --eval %configure2_5x pour connaître le détail.
Remarque : c'est la macro %configure qui est utilisée pour les anciennes versions de autoconf.
C'est une simple macro qui, de base, exécute un make avec les paramètres multiprocesseurs appropriés.
Certains projets QT (ou même autres) n'utilise pas les autotools, mais : qmake.
L'outil qmake permet de simplifier le processus de construction pour des projets utilisés sur différentes plates-formes. Il automatise la génération de Makefile, de sorte que seulement quelques lignes d'informations sont nécessaires pour créer chaque Makefile. Le développeur du projet aura créé un fichier .pro décrivant le projet avec qmake.
Dans ce cas, il faut rajouter, dans les BuildRequires :
BuildRequires: qmake
Et plus loin, dans la section %Build on aura :
qmake
make
D'autres projets utilisent cmake.
Tout comme qmake l'outil cmake permet de simplifier le processus de construction pour des projets utilisés sur différentes plates-formes. Il automatise la génération de Makefile, de sorte que seulement quelques lignes d'informations sont nécessaires pour créer chaque Makefile. Le développeur du projet aura créé un fichier CMakeLists.txt décrivant le projet avec cmake.
Dans ce cas, il faut rajouter, dans les BuildRequires :
BuildRequires: cmake
Et plus loin, dans la section %prep on aura :
%cmake
Et dans dans la section %build
make -C build avec la construction standard mageia
Cette section contient les commandes qui simulent une installation dans le dossier : BUILDROOT.
Vous trouvez ici des commandes classiques telles que mkdir, rm, mais surtout une commande install qui combine la copie et la définition des permissions du fichier copié.
Il existe également une macro : %makeinstall_std
Cette ligne installe le logiciel dans le dossier d'installation simulée pour des sources préparées par autoconf ou autre. Vous pouvez être amenés à préciser le répertoire de construction avec -C build
Cette section place les différents fichiers du répertoire BUILDROOT dans le paquetage binaire.
Vous y trouverez des lignes telles que :
%{_sysconfdir}/xdg/menus/lxqt-config.menu avec les fichiers de configuration placés dans /etc et ses sous-répertoires
%{_bindir}/lxqt-config avec les fichiers exécutables placés dans le répertoire /usr/bin
%{_libdir}/lib*.so avec les bibliothèques
%{_datadir}/lxqt/translations/%{name}-appearance
%doc README COPYING COPYRIGHT
Lorsque le paquetage binaire (le i586 ou x86_64) doit être installé ou supprimé, il est parfois nécessaire d'exécuter certaines commandes.
Il existe quatre macros qui regroupent ces commandes :
Vous placez ici les commandes qui doivent être exécutées avant l'installation du paquetage
Vous placez ici les commandes qui doivent être exécutées après l'installation du paquetage
Vous placez ici les commandes qui doivent être exécutées avant la suppression du paquetage
Vous placez ici les commandes qui doivent être exécutées après la suppression du paquetage
Elle retrace les changements successifs, avec la date, le paquageur, la version. Exemple :
* Fri Mar 27 2015 <Paiiou> 1.5.0.42-11.pai5 (Mon, Tue, Wed, Thu, Fri, Sat, Son)
- Separe plymouth from rest
- New specfile
Il n'est pas rare qu'un paquetage source permet la création simultanée de plusieurs paquetages binaires. C'est le fichier .spec qui définit l'ensemble des paquetages ainsi que leur contenu respectif.
Cela est possible en utilisant la directive %package
Ces paquets supplémentaires sont appelés sous-paquetages. Le nom des sous-paquetages dépend du reste de la ligne contenant la directive %package.
Cette directive %package joue un autre rôle dans la construction des paquetages :
Elle permet de définir des balises qui sont spécifiques à un sous-paquetage donné. Toute étiquette placée après une directive %package ne s'appliquera qu'à ce sous-paquetage.
En utilisant la directive %package suffixe, le nom du paquetage résultant est formé du nom du paquetage principal suivi de -suffixe. Exemple :
Name: mageia-theme
%package Default
donnera un paquetage mageia-theme-Default
En utilisant la directive %package -n nom, le nom du paquetage résultant est uniquement le nom donné. Exemple :
Name: mageia-theme
%package -n Themes
donnera un paquetage Themes
Les sections %files et %script spécifiques à ces sous-paquetages devront utiliser la même syntaxe, par exemple : %file Default, %pre Default ou %files -n Themes ...