Wiki » Consignes du fichier spec pour RPM-fr

Autres langues English ; français ;

Spec header

L’en-tête du fichier .spec rpm contient les informations importantes sur la version, la source, le correctif, les besoins et les exigences de compilation pour les paquets que vous souhaitez construire.

Définition des macros

La première partie du fichier .spec doit comprendre les définitions des macros, comme illustré ci-dessous :

%define major 0 %define libname %mklibname aide %{major}

Toutes les déclarations %define doivent être faites ici, avec des commentaires le cas échéant. Comme indiqué ci-dessus, il convient de les aligner correctement (utilisez deux largeurs de tabulation après la définition name ou la colonne 25 (troisième tabulation), car cela permet des noms de définition plus longs).

Remarque : Définir des macros explicites pour Name, Version et Release est inutile, car elles sont implicitement définies à partir des balises correspondantes.

Name, Version et Release

La première section doit contenir le nom standard, les étiquettes de version et de Release :

Name : aide Version : 0.13.1 Release: %mkrel 1

Name doit être le nom en amont du projet logiciel, toujours en minuscules.

Summary, Name, Sources et Patches

La section suivante de l’en-tête se présenterait comme suit :

Summary: Advanced Intrusion Detection Environment License: GPLv2+ Group: Monitoring URL: http://sourceforge.net/projects/aide Source0: http://prdownloads.sourceforge.net/aide/%{name}-%{version}.tar.gz Source1: http://prdownloads.sourceforge.net/aide/%{name}-%{version}.tar.gz.asc Source2: aide.conf Source3: aidecheck Source4: aideupdate Source5: aideinit Source6: aideinit.8 Patch0: some.patch

Comme on le voit, tout est dans un ordre très linéaire :

1. Summary tag -- Une brève description du paquetage, sur une ligne, 79 caractères maximum, pas de point a la fin, premier caractère en majuscule et sans espace
2. License tag -- Se reporter à la Politique de licence
3. Group tag -- Le groupe Mageia auquel appartient ce paquetage
4. URL -- La page d’accueil du paquetage
5. Source0... -- Les fichiers source
6. Patch0... -- Les correctifs

Les fichiers source doivent obligatoirement commencer par Source0. Ne pas utiliser Source : et ensuite Source1 : Si un paquetage n’a qu’un seul fichier source, utilisez toujours Source0, car il peut ne pas toujours avoir un seul fichier source. De même pour le terme Patch0 ; commencez toujours par Patch0 :, et jamais uniquement par Patch :. Si un fichier source a une URL téléchargeable dont il est issu, elle doit être incluse.

Attention ! Si le fichier source est mal nommé, il peut être renommé en ajoutant #/%{name}-%{version}.tar.xz à l’url SOURCE.

Les tabulations sont ici plus courtes que les définitions, en grande partie parce que les définitions peuvent être, et le sont souvent, plus longues, alors que les balises Source, Name, etc. ne le sont généralement pas. Au lieu de passer à la colonne 25, utilisez la colonne 17 ou la deuxième tabulation. Il est important que tout soit aligné à gauche pour la « deuxième colonne » ou les valeurs des mots-clés car cela maximise la lisibilité.

Nommage des Patchs (correctifs)

Il existe une méthode standard pour nommer les patchs qui est documentée dans Consignes pour empaqueter.

Build Root, Requires, etc.

La partie suivante de la norme RPM concerne les exigences de construction et c’est peut-être l’une des parties les plus fastidieuses et potentiellement incohérentes de toute norme. BuildRequires devrait être listé à chaque ligne pour une lisibilité maximale ; au lieu de regrouper plusieurs BuildRequires sur une seule ligne, utilisez une balise BuildRequires par dépendance. Tandis que RPM peut être capable de « voir » rapidement cette très longue ligne de BuildRequires, les personnes ne le peuvent pas et bien que cela puisse rendre la spécification plus longue, cela devient plus facile à lire.

Buildroot peut être omis en toute sécurité, puisqu’il est automatiquement soustrait par « rpm » lors de la construction. Pour des raisons historiques, il est toujours présent dans les spécifications de Mandriva (versions antérieures à 2008.0) mais n’est pas nécessaire pour Mageia. Cela devrait rester cohérent d’une spécification à l’autre. Par exemple :

BuildRequires: flex BuildRequires: glibc-devel BuildRequires: glibc-static-devel BuildRequires: mhash-devel BuildRequires: zlib-devel BuildRequires: bison

Requires, Obsoletes, Provides, Conflicts, etc.

Le dernier ensemble de balises dans l’en-tête RPM sont pour Requires, Obsolètes, Provides, Conflicts, etc. et elles doivent être définies au même titre que pour BuildRequires, une par ligne.

Requires(pre): foo Requires(postun): foo Conflicts: tripwire Provides: AIDE+gpg Obsoletes: bar

Encore une fois, gardez à l’esprit les tabulations. Si vous utilisez « Requires (postun)", vous passerez au-delà de la tabulation de la colonne 17. Dans ces cas, utilisez un espace unique. Notez également l'ordre. Au lieu de mélanger Requires et Provides, gardez-les dans un ordre distinct.

1. Requires, Requires (pre), Requires (post), etc. -- tous les prérequis doivent venir en premier, un par ligne
2. Conflicts -- tous les conflits passent au second plan
3. Provides et Obsoletes -- tous provides et obsoletes viennent en troisième position et peuvent être mélangées, car elles ont tendance à être étroitement liées.

Description

Le %description vient en dernier, et fournit la description du paquet. Les lignes doivent comporter 76 caractères.

Un en-tête de spec RPM final ressemblerait à :

Name : aide Version : 0.13.1 Release: %mkrel 1 %define major 0 %define libname %mklibname aide %{major} %define somereallylongname foo Summary: Advanced Intrusion Detection Environment License: GPLv2+ Group: Monitoring URL: http://sourceforge.net/projects/aide Source0: http://prdownloads.sourceforge.net/aide/%{name}-%{version}.tar.gz Source1: http://prdownloads.sourceforge.net/aide/%{name}-%{version}.tar.gz.asc Source2: aide.conf Source3: aidecheck Source4: aideupdate Source5: aideinit Source6: aideinit.8 Patch0: some.patch Buildrequires: flex BuildRequires: glibc-devel BuildRequires: glibc-static-devel BuildRequires: mhash-devel BuildRequires: zlib-devel BuildRequires: bison Requires: gnupg Requires(pre): foo Requires(postun): foo Conflicts: tripwire Provides: AIDE+gpg Obsoletes: bar %description AIDE (Advanced Intrusion Detection Environment) est une alternative gratuite aux Tripwire. Il fait les mêmes choses que le Tripwire semi-libre et plus encore. C’est un outil de surveillance de l’intégrité du système de fichiers.

Pour les paquetages qui créent plusieurs sous-paquets, suivez les directives ci-dessus pour chacun d’eux.

%prep

La section %prep suit toutes les définitions de paquets. Il devrait y avoir au moins deux lignes blanches pour séparer la fin de la dernière %description de %prep. Une simple section %prep ressemblerait à :

%prep %setup -q

Autres conventions

Voici une liste des autres conventions qui doivent être observées dans les fichiers spec de Mageia :

Macros système et macros définissables par l’utilisateur

Les macros système sont celles définies dans les fichiers /etc/rpm/macros.d/ et incluent notament %_install_info, entre autres. Une macro système est quelque chose qui fait quelque chose ou calcule quelque chose. Ce n’est pas une simple définition comme %{_tmppath} qui se traduit simplement par un chemin. Les macros système doivent être écrites sans accolades, c’est-à-dire au format %_install_info et non %{_install_info}. Les macros définissables par l’utilisateur, qui incluent %{_tmppath} ou %{_bindir} doivent être écrites avec des accolades, c’est-à-dire au format %{_tmppath} et non %_tmppath. Cela facilite la lecture de la spécification car tout le monde utilisera une convention similaire pour les « accolades ». Si vous n’êtes pas sûr de savoir lequel utiliser, gardez à l’esprit qu’une macro comme %{_libdir} fournit une valeur (dans ce cas, /usr/lib), alors qu’une macro comme %_install_info exécute en fait du code de toute sorte.

• Utilisez %{_libdir}, plutôt que %_libdir
• Utilisez %_install_info, plutôt que %{_install_info}

Utilisez systématiquement ce mécanisme et tous les fichiers de spécifications seront beaucoup plus faciles à lire.

Macro standard

Le fait de conserver les noms de macros cohérentes dans les fichiers de spécifications améliore la lisibilité.

•  %{upstream_name} lorsque le nom de la version en amont diffère de celui de la version du paquetage
•  %{upstream_version} lorsque la version en amont diffère de celle du paquetage

Variables

Les variables qui sont vraiment des définitions, comme $RPM_OPT_FLAGS ou $RPM_BUILD_ROOT ne doivent pas être utilisées. Les macros telles que %{optflags} et %{buildroot} doivent être utilisées à la place. Gardez Les variables "$*" strictement limitées aux construction liées au shell et non aux définitions basées sur RPM.

Journal des modifications

Jetez un oeil à notre Consignes pour empaqueter-Journal des modifications

Gestion des sources

Les fichiers sources ont généralement été traités en utilisant des macros %{SOURCExx}, mais ceci est inefficace pour quelques raisons simples :

• pas besoin de monter et descendre dans le fichier spec pour comprendre ce qu’est %{SOURCE12}.
• les fichiers sources peuvent être facilement renumérotés sans avoir à effectuer de multiples modifications

Au lieu de cela, utiliser %{_sourcedir}/foo dans le fichier spec est préférable, car il rend les choses plus faciles à lire et plus faciles à travailler. Par exemple, comparez:

Source12: something.pam … install -m 0644 %{SOURCE12} %{buildroot}%{_sysconfdir}/pam.d/

vers:

Source12: something.pam … install -m 0644 %{_sourcedir}/something.pam %{buildroot}%{_sysconfdir}/pam.d/

Les fichiers sources ne doivent pas contenir les macros %{version} ou %{name} sauf s’il s’agit des fichiers sources originaux en amont.

Les fichiers patch ne doivent jamais contenir les macros %{version} ou %{name}.

Resources

• Fedora's guidelines:
  • How to create a GNU Hello RPM package;
  • How to create an RPM package;
• Packaging guidelines.
  • Mageia RPM HOWTO - the Mageia RPM HOWTO (contains good information and should be seen as supplemental to this policy)

Changements et suggestions possibles en fonction de la proposition

• Cette section détaille certaines modifications techniques qui ne font pas partie de la proposition, mais qui devront peut-être être mises en œuvre pour que la proposition soit la plus efficace possible :

Les choses obsolètes, devraient être jetées là où on les voit

Le mgagnome a une sous-commande clean-spec pour vous faciliter cela.

• %clean section, est maintenant réalisée automatiquement par RPM lui-même
• rm -rf %{buildroot} n’est plus nécessaire explicitement dans %install puisque cela si fait automatiquement
• BuildRoot: définition
• %defattr(-,root,root) est inutile, doit être retiré. Utilisez %defattr uniquement si vous voulez vraiment changer les permissions par défaut en amont. De tous les fichiers suivants après la macro %defattr. C’est rarement nécessaire.
• changer %py_requires en BuildRequires: python
• changer %py_requires -d en BuildRequires: python et BuildRequires: python-devel
• supprimer des variables telles que name, version, release si elles ne sont pas définies de manière conditionnelle. Par exemple :

1. fichier de spécifications avec des variables inutiles pour name/version/release

%define name modulename %define version 1.2.3 %define release %mkrel 1 Name: %name Version: %version Release: %release

1. Procédez comme suit à la place:

Name: modulename Version: 1.2.3 Release: %mkrel 1

Voir également

• Mageia-Mandriva-Fedora-SUSE RPM Spec Lingo - a lingo for the equivalents of the various RPM spec macros in the various distributions.