From Mageia wiki
Jump to: navigation, search
Drakconf multiflag.png
Autres langues

Anglais ; français


Ce tutoriel est destiné à aider ceux qui voudraient produire des paquetages logiciels bien intégrés à la distribution Mageia GNU/Linux. Il insiste sur les (légères) différences entre ces paquetages et ceux destinés à d’autres distributions utilisant les RPM. Ce document devrait être utile aux développeurs Mageia mais aussi à tous les utilisateurs intéressés par la création de paquetages. La distribution Mageia Linux est éditée et distribuée par la communauté bénévole de Mageia.org, avec l’aide de nombreux contributeurs, testeurs et traducteurs.


Avant-propos

Dans ce document, nous supposons que le lecteur est familiarisé avec un système GNU/linux. Il connait les commandes de base, la structure des répertoires et a déjà utilisé la commande rpm, ne serait-ce que pour installer des paquetages.

Ce document est construit comme une recette pas à pas pour obtenir un paquetage .rpm qui s’intègre bien à la distribution Mageia, que ce soit à partir d’un rpm source ou à partir d’une archive tar.

En bref, RPM désigne trois choses :

  • un programme pour créer ou installer des paquetages ;
  • un format utilisé dans des paquetages (source ou binaire) créés par le programme Rpm ;
  • un fichier appelé paquetage qui contient les sources ou le binaire ainsi qu’une en-tête d’information sur la méthode d’installation ou de désinstallation du programme.

Du point de vue de l’utilisateur, le programme rpm est un remarquable programme de gestion de paquetages. Il pilote en fait toutes les actions sur un paquetage RPM. Il peut ainsi, entre autres :

  • installer ou mettre à jour un paquetage en vérifiant ses dépendances ;
  • exécuter des actions pendant l’installation pour rendre le programme installé prêt à l’emploi ;
  • restaurer des fichiers d’un paquetage effacés accidentellement ;
  • dire si un paquetage est déjà installé ;
  • trouver de quel paquetage provient un fichier particulier ;
  • vérifier l’installation courante et le respect des dépendances pour tous les paquetages installés ;

Du point de vue du programmeur, le programme rpm est un empaqueteur qui encapsule dans un seul fichier .rpm toutes les informations nécessaires à l’installation d’un programme sur une plate-forme donnée.

Il est important de distinguer dès le début les paquetages sources (.src.rpm) et les paquetages binaires (.<archtype>.rpm).

Les premiers contiennent l’arborescence entière des sources du programme, plus tout ce que le réalisateur du paquetage a ajouté pour qu’il puisse être configuré, compilé et finalement installé. Cela consiste généralement en un fichier ayant l’extension .spec (le fichier utilisé pour dire à rpm les opérations à effectuer pour créer le paquetage binaire) ainsi que des correctifs, si nécessaire.

Les seconds contiennent le binaire compilé, ainsi que tous les fichiers (documentation, fichiers de configuration, icônes…) qui seront installés sur le système cible. Ils contiennent aussi la procédure qui installe les fichiers aux emplacements corrects, ainsi que les actions qui rendent le programme opérationnel.


Installer le logiciel

Les bases

Bien que RPM ait été conçu à l’origine pour la distribution Red Hat Linux, « Red Hat Package Manager », donc « RPM » il a été adopté par d’autres distributions : OpenMandriva, Qubes OS, Suse, etc. rpm est déja installé sur ces systèmes.

Les rpm binaires que vous construirez pour Mageia ne fonctionnent pas forcément sur toutes les distributions, ni même sur toutes les versions de Mageia, bien que des efforts soient fait pour rester compatible avec Red Hat.

Construire des paquetages pour Mageia

Construire des paquetages pour Cauldron (la version de développement de Mageia Linux) est toujours sujet à de petits patchs et améliorations apportés au programme RPM en cours. Récupérez sur un miroir Cauldron :

  • Le paquetage rpm qui est notre version patchée de celui de Red Hat.
  • Le paquetage rpm-build qui contient des scripts destinés à construire des paquetages.
  • Le paquetage spec-helper, qui est un outil qui minimise les fichiers specs en faisant automatiquement des opérations telles que diminuer la taille des binaires et compresser les pages du manuel man.
  • Le paquetage libtool, utilisé par certains scripts de configuration pour construire des bibliothèques de fonctions partagées.
  • Le paquetage rpmlint qui est utilisé pour vérifier la validité du paquetage src.rpm généré.

Tâches préliminaires

Installer les paquetages requis

Pour pouvoir construire des RPM, vous devez avoir installé au préalable le paquetage rpm-build. Pour savoir comment installer des paquetages, veuillez vous référer à la page Gestion des logiciels.

Créer les répertoires requis

Pour construire des paquetages, RPM a besoin d’une arborescence spéciale dans le dossier personnel de l’utilisateur. Cette arborescence peut être créée en tapant dans une console :

Konsole.png
[user@computer ~]$ mkdir -p ~/rpmbuild/{SRPMS,SOURCES,SPECS,tmp}


Warning.png
Attention !
Il est dangereux de construire des RPM en tant que root, puisque les fichiers binaires sont installés sur le système avant d’être empaquetés. Il faut donc toujours construire ses RPM en tant qu’utilisateur normal afin de ne jamais polluer accidentellement son système.


Vérifiez bien que l’arborescence est de la forme :

  • ~/rpmbuild/BUILD : dossier où se fait la compilation des sources.
  • ~/rpmbuild/BUILDROOT : Le répertoire où l’installation sera simulée
  • ~/rpmbuild/RPMS : contient les répertoires, un par architecture, qui contiendront les paquetages binaires générés.
  • ~/rpmbuild/RPMS/i586 : le répertoire où seront stockés les paquetages binaires créés pour les processeurs i586.
  • ~/rpmbuild/RPMS/x86_64 : le répertoire où seront stockés les paquetages binaires créés pour les processeurs X86_64.
  • ~/rpmbuild/RPMS/noarch : le répertoire où seront stockés les paquetages binaires “noarch” (c’est-à-dire indépendants de l’architecture du processeur). générés. Ndla : c’est souvent le cas des applications écrites dans des langages interprétés (php,perl,python,ruby…).
  • ~/rpmbuild/SOURCES : contient les fichiers sources (par exemple mon_paquetage.tar.bz2).
  • ~/rpmbuild/SPECS : contient les fameux fichiers spec que nous devons écrire.
  • ~/rpmbuild/SRPMS : RPM sources après la construction.
  • ~/rpmbuild/tmp : dossier temporaire de travail pour RPM.
Notepad.png
À noter !
Les dossiers d’architecture sous ~/rpmbuild/RPMS sont indispensables. S’ils manquent, un message d’erreur s’affichera.


Créer le fichier .rpmmacros

Pour pouvoir construire des paquetages pour Mageia, vous devrez au préalable créer le fichier de configuration .rpmmacros dans votre répertoire personnel et y copier/coller le contenu ci-dessous

# rpm build settings

# directory overrides
%_topdir         %(echo $HOME)/rpmbuild/
%_tmppath        %(echo $HOME)/rpmbuild/tmp

# package signature add automatically (name as assigned, for example, by GnuPG)
# packages can be signed later with `rpm --resign`
%_signature      gpg
%_gpg_name       John Doe
%_gpg_path       ~/.gnupg

# packager, distributor, and vendor override
# for vendor consider using personal name
%packager        John Doe <foo@example.com>
#%distribution    Mageia
#%vendor          Mageia.Org

# distribution name suffix override
#%distsuffix      mga

# distribution name override
#%dis             mageia

Construire un RPM

À partir d’un RPM source existant

C’est généralement le cas pour les paquetages qui font partie intégrante de la distribution.

Les derniers fichiers rpm de Cauldron sont disponibles sur de nombreux miroirs dont la liste est disponible ici. Dans cette hiérarchie, on trouve les répertoires :

  • SRPMS : pour les RPM sources (« core », « nonfree », « tainted ») et pour les architectures cpu (par ex. i586, x86_64 …) :
    • media/core : pour les RPM binaires de « core » ;
    • media/nonfree : pour les RPM binaires de « nonfree » ;
    • media/tainted : pour les RPM binaires de « tainted » ;

Une fois téléchargé le RPM source à modifier pour Mageia dans le dossier ~/rpmbuild/SRPMS, exécutez simplement rpm -ivh mypackage.src.rpm et ceci installera toutes les sources dans le répertoire ~/rpmbuild/SOURCES. On peut aussi configurer urpmi pour télécharger les sources (voir Installation de sources d’un paquet)

Par exemple :

Konsole.png
[user@computer ~]$ rpm -i SRPMS/ktron-1.0.1-2mdk.src.rpm

Puis ensuite pour vérifier que la source le fichier « spec » ont bien été installés :

Konsole.png
[user@computer ~]$ ls -R ~/rpm

BUILD :

RPMS : noarch/ i386/ i586/ i686/

SPECS: ktron.spec

SOURCES: ktron-1.0.1.tar.bz2

SRPMS:

tmp


On voit que rpm a installé dans notre arborescence ~/rpm le fichier source ktron-1.0.1.tar.bz2 et le fichier spec. Même avant de construire une nouvelle version d’un paquetage, il peut être utile de faire un « build » sur le paquetage courant pour comprendre comment il est compilé et s’il compile. La commande magique pour cela est rpmbuild avec l’option -ba:

Konsole.png
[user@computer ~]$ cd ~/rpmbuild/SPECS
Konsole.png
[user@computer ~]$ rpmbuild -ba ktron.spec

Si la construction se termine sans erreur (cela peut durer des heures pour des paquetages comme les kernels), on retrouve le RPM binaire et le RPM src respectivement dans les répertoires ~/rpmbuild/RPMS/i586 et ~/rpmbuild/SRPMS/. Le fichier log de l’opération de construction, qui peut être très long, peut être enregistré pour le relire plus tard.

Konsole.png
[user@computer ~]$ ls -l ~/rpmbuild/RPMS/i586/ktron-1.0.1-2mdk.i586.rpm
Konsole.png
[user@computer ~]$ ls -l ~/rpmbuild/SRPMS/ktron-1.0.1-2mdk.src.rpm


Pour installer le RPM binaire, il faut être sous root, mais c’est inutile pour construire un .rpm ou décompresser un .src.rpm.

On retrouve dans les sous-répertoires ~/rpmbuild/BUILD les sources patchées (si un ou plusieurs patchs ont été fournis dans ~/rpmbuild/SOURCES), les binaires, les librairies compilées, les pages de man, etc. Le fichier « spec » décrit les fichiers source et les patchs à appliquer avant construction, ainsi que la manière de construire le paquetage et de l’installer.

Il ne nous reste plus (dans cet exemple pour améliorer ktron) qu’à modifier le fichier « spec » et à reconstruire le paquetage.

Il est important de noter que chaque paquetage intégré dans Mageia est stocké sur un système SVN, visible via l’interface web. Ainsi, les états successifs du paquetage sont enregistrés, de sorte que le développeur peut consulter les archives pour vérifier des modifications précédentes et éventuellement revenir à une version précédente du logiciel.

Chaque fichier spec est donc disponible dans un sous-dossier portant le nom du logiciel dans le dossier packages/cauldron.

Vous pouvez y accéder sur http://svn.mageia.org/

Pour plus de détails sur la façon d'accéder au système SVN, consultez le guide Mageia SVN.

Enfin, le répertoire BUILDROOT est l’endroit où le paquet est installé avant d’être intégré dans un RPMS binaire. Ce répertoire est généralement vide si la compilation réussit, mais ce n’est pas le cas lorsque la compilation échoue. Il peut être intéressant de voir ce qui s’est mal passé : par exemple, des fichiers installés dans un mauvais répertoire à cause d’une faute de frappe pour une macro qui se développe vers un chemin du fichier spec

À partir d’une archive tarball

Par exemple, si vous trouvez un programme intéressant sur Sourceforge qui vous avertit quand le thé est prêt, vous pouvez le rendre disponible sur Mageia pour tous les buveurs de thé anglais. La meilleure façon d’y parvenir est probablement d’établir un RPM conforme aux standards de Mageia.

Téléchargez l’archive tarball et placez-la dans l’annuaire SOURCES.

Vérifications préliminaires

  • Licence : Malgré la prédominance de la licence GPL, il existe d’autres licences libres (comme BSD, MIT, etc) ou non libres. Vérifiez attentivement la licence du logiciel pour déterminer si ce programme peut être incorporé ou non à la distribution. En effet, nous n’acceptons pas de logiciels non libres, sauf dans la section non-free. Nous ne pouvons pas non plus accepter de logiciels dont la licence ne nous permet pas de les distribuer librement. Attention à ces programmes. Vérifiez donc au préalable si un logiciel est acceptable d’après sa licence.
  • Compression de l’archive : Pour simplifier la maintenance, il est recommandé d’utiliser la méthode de compression utilisée par l’auteur ou le développeur, sans aucunes modifications. Si les sources sont fournies dans plusieurs formats de compression, nous choisissons généralement le .tar.bz2, ou un meilleur algorithme de compression, comme tar.xz. Évitez de compresser les fichiers au format texte (comme les patchs produits par diff et autres, les fichiers de configuration, les scripts, etc.). Leur compression économiserait très peu d’espace tout en rendant plus difficile la visualisation des changements, au niveau des diffs produits par Subversion.
Notepad.png
À noter !
Pour les paquetages logiciels sensibles, nous recommandons de conserver le format originel de l’archive afin de ne pas altérer le checksum/signature. Ainsi, lorsque quelqu’un souhaitera vérifier la signature des sources via les programmes md5sum, sha1sum ou gpg, il pourra obtenir un résultat équivalent à la valeur indiquée sur le site de téléchargement. Un exemple où cette exception peut s'appliquer serait « OpenSSH »

.

Anatomie du fichier .spec

C’est la partie la plus importante de ce document. Le fichier spec contient toutes les informations dont RPM a besoin pour :

  • compiler le programme et construire les RPM binaires et sources,
  • installer ou désinstaller le programme sur la machine de l’utilisateur final.

Le débutant peut être dérouté par le fait que ces deux types d’information sont regroupés dans un seul fichier. Cela est dû à l’arborescence de l’archive tar source, qui contient déjà cette information. Comme la procédure d’installation est extraite au cours du processus d’installation, généralement lancé par un make install dans l’arborescence source, les deux parties sont intimement liées.

En bref, le fichier spec décrit une compilation et une installation simulée, dit à RPM quels fichiers résultants de cette installation doivent être mis dans le paquetage et finalement comment installer ces fichiers dans le système de l’utilisateur. Les commandes sont exécutées en utilisant le shell /bin/sh, de telle sorte que des commandes comme [-f configure.in] && autoconf sont valides.

Nous n’allons pas exposer ici en détail toutes les possibilités d’un fichier spec. Le livre Maximum RPM (cf. section 7) l’explique en profondeur. Nous allons nous contenter de passer en revue les options utilisées dans un exemple de fichier spec standard Mageia.

Plus vous construirez de RPM, plus vous découvrirez d’options dont nous n’avons pas parlé. RPM est très extensible, nous laissons donc au lecteur le soin de découvrir toutes ces options à titre d’exercice. Il est toujours bon d’ouvrir des fichiers specs et d’y jeter un coup d’œil pour comprendre leur fonctionnement.

Le lecteur peut également consulter une liste de specs et de correctifs.

  Name:           gif2png
  Version:        2.0.1
  Release:        %mkrel 1
  Summary:        Tools for converting websites from using GIFs to using PNGs 
  Source0:        http://www.tuxedo.org/~esr/gif2png/%{name}-%{version}.tar.bz2 
  Source1:        %{name}-%{version}-mga-addon.tar.bz2 
  Patch0:         gif2png-2.0.1-bugfix.patch
  URL:            http://www.tuxedo.org/~esr/gif2png/ 
  
  Group:          Applications/Multimedia 
  License:        MIT-like 
  Requires:       python 
  
  %description
  Tools for converting GIFs to PNGs. The program gif2png converts GIF files
  to PNG files. The Python script web2png converts an entire web tree, also
  patching HTML pages to keep IMG SRC references correct.
  
  %prep 
  %setup -q -a 1 
  %patch -p1 
  
  %build 
  %configure 
  %make_build
  
  %install
  rm -rf %{buildroot}
  %make_install
  
  %files 
  %defattr(0755,root,root) 
  %doc README NEWS COPYING AUTHORS 
  %{_mandir}/man1/gif2png.1*
  %{_mandir}/man1/web2png.1*
  %{_bindir}/gif2png 
  %{_bindir}/web2png 
  
  %changelog 
  * Mon Nov 02 2010 Camille Begnis <camille@mageia.org> 2.0.1-1.mga1
  - Upgraded to 2.0.1 
  
  * Mon Oct 25 2011 Camille Begnis <camille@mageia.org> 2.0.0-1.mga1
  - Specfile adaptations for Mageia
  - add python requirement
  - gz to bz2 compression


Analysons en détail chaque ligne de ce fichier :

Attention, un % au début d’une ligne peut signifier soit :

  • le début d’une section (prep, build, install, clean)
  • un script de macro du shell (setup, patch)
  • une instruction utilisée par une section spéciale (defattr, doc, …)

Vous pouvez voir à quoi correspond une macro à l’aide de l’instruction rpm --eval

rpm --eval "%mkrel 1 »
1mdv2010.0


Section En-tête

%define name gif2png
%define version 2.0.1
%define release %mkrel 1

Ces 3 lignes définissent des constantes utilisables par les sections suivantes du spec, constantes qui seront alors nommées %{name} , %{version} et %{release} . %mkrel est une macro Mageia qui doit être utilisée pour ajouter le suffixe « mga » et la version de la distribution après le numéro de révision du paquet.

Nous pouvons maintenant remplir certains champs d’information pour rpm :

Name : %{name}

C’est le nom du paquetage tel qu’il sera identifié sur la machine de l’utilisateur et dans sa base de données de paquetages une fois installé.

Noter que "%{name} " se réfère au « define » précédent.

Version : %{version}
Release : %{release}

Il est maintenant temps d’expliquer comment est formé le nom d’un paquet. Il est important de toujours respecter ce standard pour que votre travail soit compréhensible par les autres.

Il existe beaucoup d’autres champs que vous pourriez désirer connaître, mais qui ne sont pas dans notre fichier spec exemple. Vous pourriez en rencontrer certains. Il est peu probable que vous arriviez à tous les retenir si vous commencez tout juste à construire des RPM. Mais après quelque temps, cette liste sera une bonne référence !

  • Un paquetage binaire se nomme ainsi : name-version-release.arch.rpm
  • Un paquetage source se nomme ainsi : name-version-release.src.rpm (par ex : gif2png-2.0.1-1mdk.src.rpm pour notre exemple)

Le « nom » est généralement celui de l’exécutable principal du paquetage, bien qu’on puisse choisir un autre nom pour des raisons valables.

La « version » est le numéro de version des sources non patchées, numéro qu’on retrouve dans le nom de fichier de l’archive d’origine : name-version.tar.gz.

La « release » est un nombre, incrémenté à chaque nouvelle construction du paquetage, suivi d’un suffixe indiquant pour quelle distribution a été construit le paquetage, par exemple « mga2014.1 » pour « Mageia 2014.1 ». Notez que cette extension est obligatoire. Un paquetage peut être reconstruit pour de multiples raisons : l’ajout d’un nouveau correctif (patch) aux sources, une modification du fichier spec, l’ajout d’une icone, etc.

Summary : tools for converting websites from using GIFs to using PNGs

Le « Summary » est une courte description du paquetage, en une seule ligne. Il est important qu’on puisse comprendre ce que fait le paquet à partir de ce champ, et que cela ne dépasse pas une certaine limite (80 caractéres).

Source0 : http://www.tuxedo.org/~esr/gif2png/%{name}-%{version}.tar.bz2

Cette ligne indique à rpm le fichier source à utiliser pour construire ce paquetage. À noter que le nom est précédé d’une URL complète (optionnelle) pointant vers le site où sont disponibles les sources d’origine ; rpm enlève l’URL, ne gardant que le nom de fichier et cherche ce fichier dans le dossier ~/rpmbuild/SOURCES. Bien que l’URL complète soit optionnelle, elle est recommandée pour que les utilisateurs sachent où trouver les nouvelles sources pour les mettre à jour et recompiler le programme. De plus, cela permet à des outils comme mdvsys de reconstruire automatiquement de nouvelles versions (cf. en:Development/Packaging/Tools/rpmbuildupdate pour plus d’infos).

S’il y a plus d’un fichier source, on ajoute d’autres lignes sources, comme : Source1 : …, puis Source2 : …, etc.

Patch0 : gif2png-2.0.1-bugfix.patch

Deux raisons à ce champ optionnel :

  1. Vous avez corrigé un bogue dans les sources du programme. Vous avez donc généré un correctif, à appliquer aux sources du programme avant compilation.
  2. Vous avez appris l’existence sur le net d’un correctif ou d’une amélioration pour votre version du programme et vous l’avez téléchargé.

Il faut éviter d’ajouter trop d’améliorations extérieures, car elles induisent du travail lors de la mise à jour du paquet. De même, si jamais vous avez intégré à un paquet un correctif que vous avez écrit, il est requis de l’envoyer au développeur du logiciel afin qu’il l’ajoute au code-source, et ainsi partager le travail avec la communauté du libre.

Notepad.png
À noter !
Les fichiers patchs doivent être placés dans le dossier même dossier que les sources (~/rpmbuild/SOURCES). Comme pour les sources, il peut y avoir plusieurs correctifs. Ils seront alors désignés dans le fichier spec par des lignes Patch1 : …, puis Patch2 : …, etc.


URL : http://www.tuxedo.org/~esr/gif2png/

Cette ligne (optionnelle mais recommandée) pointe vers la page Web du programme.

Group : Multimedia

Ceci indique à rpm à quel emplacement de l’arborescence générale des paquetages placer ce paquetage. Cette information est utilisée par les gestionnaires de paquets tels que rpmdrake.

La structure complète des groupes à utiliser, différente de celle de Red Hat, se trouve sur la page RPM groups policy (en). Il faut absolument s’y conformer pour que vos paquetages ne se mélangent pas aux autres dans l’arborescence système de l’installeur Mageia, ou dans les gestionnaires de paquets.

License : MIT-like

Ce champ (qui remplace « Copyright ») définit la licence choisie par le propriétaire du Copyright (ou droits d’auteur) qui s’applique au programme empaqueté. C’est le plus souvent la license GPL. Voir la page Politique en matière de licences de mageia et celle-ci pour une liste des licences autorisées.

Requires : python

Cette ligne a été ajoutée parce qu’un des programmes du paquetage est un script python. Il a donc besoin de l’interpréteur python pour fonctionner. On peut optionnellement demander une numéro de version minimal en ajoutant un signe supérieur (ou égal), par exemple : Requires : python >= 1.5.1. En pratique, les nouvelles versions de rpm arrive à rajouter la dépendance automatiquement.

%description
Tools for converting GIFs to PNGs. The program gif2png converts GIF files
to PNG files. The Python script web2png converts an entire web tree, also
patching HTML pages to keep IMG SRC references correct.

Ce champ est spécial parmi ceux de l’en-tête du fichier spec, car c’est un texte entier pouvant faire plusieurs lignes ou paragraphes si nécessaire. C’est une description complète du programme qui va être installé, pour aider l’utilisateur à décider s’il veut installer ou non ce paquetage.

Vous vous demandez peut-être : « Et les traductions ? » En fait, pour améliorer la lisibilité des fichiers spec, les traductions des champs « Summary » et « description » sont stockés dans un fichier spécial nommé <package>.po.

Ces fichiers sont stockés dans le module poSPECS du cvs de cooker ['“FIXME”': est-ce encore le cas ? Les fichiers n’ont pas été modifiés en 5 ans…]. Quand un nouveau paquetage est créé, le fichier po de base est automatiquement créé dans ce module pour traduction ultérieure.

Cette méthode suppose que tous les textes d’un fichier .spec sont écrits en anglais. A l’exception toutefois des paquetages dédiés à un langage précis (ispell-de par exemple). Il est dans ce cas recommandé d’écrire le texte dans les deux 2 langues : anglais et le langage spécifique. On utilise alors les champs spéciaux : Summary(de) : … et %description -l de.

Section Prep

%prep
%setup -q -a 1
%patch0 -p1

Cette section contient le script exécuté en premier par rpm. Son rôle est de :

  • créer le dossier racine pour la construction (dans BUILD),
  • décompresser les sources originales dans le dossier ~/rpmbuild/BUILD,
  • appliquer aux sources les correctifs éventuels.

Elle peut être suivie de toute commande voulue par le créateur du paquetage pour que les sources soient prêtes pour la compilation.

%setup -q -a 1

Ceci est un script pré-défini qui :

  • exécute une commande cd dans l’arbre de compilation,
  • extrait les sources (silencieusement, -q),
  • change le propriétaire et les permissions des fichiers sources.

Par défaut, il n’extrait que le premier source. Il faut utiliser des paramètres pour des sources supplémentaires : dans notre exemple, -a 1 dit que nous voulons aussi extraire le source numéro 1.

La macro %setup a d’autres options intéressantes :

  • -c name : l’option « -c » demande de créer d’abord le répertoire racine “nom”, puis de s’y déplacer par cd et de décompresser Source0. C’est utile pour certains paquetages qui ont été « tar.bz-ippés » sans répertoire parent.
  • -D : ne pas effacer le répertoire avant décompression. Cela ne sert que s’il y a plus d’une macro %setup. À utiliser seulement dans les %setup qui suivent le premier (mais jamais dans le premier).
  • -T : cette option remplace l’action par défaut de décompresser la Source (et nécessite alors un -b 0 ou -a 0 pour décompresser le fichier source principal). Nécessaire quand il y a des sources secondaires.
  • -n <name> : à utiliser si le nom du rpm est différent de celui en lequel se décompresse le Source. Par exemple, si le rpm se nomme program-version-revision et que le Source se décompresse en program-version-date, le processus de build du rpm ne pourra pas entrer (cd) dans le répertoire program-version, il faut alors utiliser « -n program-version-date », pour que rpm sache dans quel nouveau répertoire il doit continuer.
%patch0 -p1

Cette macro applique le patch aux sources ; son paramètre "-p<numero>" est passé au programme patch. Supposons qu’il y ait un autre patch déclaré dans la section en-tête par de Patch1 : … ; il faut ajouter une autre ligne : %patch1 -p1. Il peut être utile d’ajouter l’option -b .your_suffix pour signaler aux autres ce que fait votre patch, ou qui l’a créé. Par exemple, si le patch est de David_david, on peut faire %patch -p1 -b .David_david. Si c’est Papoteur qui l’a fait, le patch peut être %patch -p1 -b .Papoteur

Section Build

%build

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.

%configure2_5x
C’est la ligne, qui configure les sources utilisant autoconf. %configure2_5x lance un ./configure avec de nombreuses options telles que
export CFLAGS="$RPM_OPT_FLAGS"
avant le configure, et des options telles que
i586-mageia-linux-gnu --prefix=/usr --datadir=/usr/share
etc.

Ces arguments ne sont pas toujours gérés par le script de configuration. Dans ce cas, il faut en découvrir la raison puis lancer ./configure avec les paramètres appropriés. Si cela est géré, on passe le nom de la plateforme cible à l’appel de configure par %{“target”platform} . Bien sûr, il faut éviter de spécifier l’architecture dans un fichier spec ; sur un ix86, ce paramètre se développera en i586-mageia-linux-gnu, comme vu plus haut.

Notepad.png
À noter !
Le paquetage '“libtool”' est nécessaire pour utiliser la macro %configure2_5x avec des paquetages qui construisent des bibliothèques partagées.


Quand on construit et qu’on teste un paquetage, il faut vérifier que l’hôte cible est bien un i586 ; en particulier, quand on compile sur un processeur d’un type supérieur, par défaut, le script trouve le processeur architecture et optimise pour lui. La macro %configure est là pour passer outre ce comportement si besoin est.

%make

C’est une simple macro qui, de base, exécute un make avec les paramètres multiprocesseurs appropriés -j<num>.

Pour des sources qui utilisent xmkmf, remplacer le make suivant par :

make CDEBUGFLAGS="$RPM_OPT_FLAGS » CXXDEBUGFLAGS="$RPM_OPT_FLAGS »

Pour les autres paquetages, dans la plupart des cas (mais pas tous), un simple make suffit.

Section Install

%install

Cette section contient le script qui installe vraiment le paquet dans le dossier d’installation simulée : $RPM_BUILD_ROOT.

Ce sont les commandes qui rendent le logiciel fonctionnel sur le système de l’utilisateur.

rm -rf $RPM_BUILD_ROOT

C’est la première commande exécutée dans la section %install qui nettoie le dossier d’une éventuelle précédente installation.

%makeinstall
Cette ligne installe le logiciel dans le dossier d’installation simulée pour des sources préparées par autoconf. Cette macro se développe en "make install" avec diverses options pour que le logiciel soit installé dans le dossier d’installation simulée $RPM_BUILD_ROOT, par exemple
prefix=$RPM_BUILD_ROOT%{_prefix} bindir=$RPM_BUILD_ROOT%{_bindir}
etc. Il arrive que le script de configuration soit partiellement cassé auquel cas il faudra aller fouiner dans les fichiers Makefile pour deviner les paramètres optionnels à passer pour que le logiciel s’installe correctement. Une des situations les plus courantes est d’avoir à utiliser
make DESTDIR=$RPM_BUILD_ROOT install
.

Pour économiser à la fois de l’espace disque et du temps de téléchargement, Mageia utilise xz. Cet aspect est cependant pris en charge en standard par la version de rpm de Mageia.

De même que pour les anciennes lignes $RPM_BUILD_ROOT%{_bindir}/* || : il faut les supprimer.

Tout ceci prépare les fichiers à être empaquetés.

%clean

Cette section nettoie le dossier de construction $RPM_BUILD_ROOT.

rm -rf $RPM_BUILD_ROOT

C’est ici que se fait le travail.


Section files

%files

Cette section est une liste de fichiers à prendre dans le dossier d’installation simulée pour les incorporer au paquetage. Voir le manuel pour d’autres options absentes de cet exemple simple.

La liste des fichiers doit être écrite à la main dans le fichier spec. On peut la construire en listant tous les fichiers créés par rpm dans le répertoire de construction. Pour cela, on exécute un rpm -bi mypackage.spec pour arrêter le processus de construction juste après l’installation simulée. On examine alors le contenu du dossier d’installation simulée, ~/rpmbuild/tmp/gif2png-buildroot dans notre cas, pour voir quels fichiers on veut mettre dans le paquetage (le plus souvent, on les met tous).

Notepad.png
À noter !
sur la structure des répertoires : les fichiers installés par votre paquetage doivent suivre les recommandations FHS disponibles sur [1].


%defattr(-,root,root)

Ce champ définit les attributs à appliquer à chaque fichier qui sera copié sur le système de l’utilisateur. Les quatre arguments donnés signifient :

  • - : tous les attributs des fichiers réguliers restent inchangés,
  • root : le propriétaire du fichier est root,
  • root : le groupe propriétaire du fichier est root,
  • (optionnel) 0755 : les attributs du groupe propriétaire appliqués à tous les répertoires possédés par ce paquetage sont 0755 (rwxr-xr-x).
%doc README NEWS COPYING AUTHORS

Le champ spécial %doc désigne les fichiers qui font partie de la documentation du paquetage. Les dits fichiers seront placés dans /usr/share/doc/gif2png/. Ce dossier sera aussi automatiquement créé. Les fichiers spécifiés par %doc sont placés relativement au répertoire source décompressé dans BUILD.

%{_mandir}/man1/gif2png.1*
%{_mandir}/man1/web2png.1*

Il est recommandé de lister ici aussi chaque fichier man ou info séparément.

Aussi, vous vous demandez peut être pourquoi dire gif2png.1* et non pas gif2png.1.xz. C’est pour préserver la compatibilité avec les autres systèmes qui pourraient utiliser la compression xz. Si on trouve de telles références à xz dans des fichiers specs, les remplacer par un joker. Le plus souvent, on peut aussi utiliser %{_mandir}/man1/* qui prendra tous les fichiers qu’il trouvera.

%{_bindir}/gif2png
%{_bindir}/web2png

On peut voir qu’il y a des macros pour chaque type de chemin nécessaire. Voici les plus utiles (regardez dans /usr/lib/rpmbuild/macros pour les avoir toutes) : %{_prefix} , %{_bindir} , %{_sbindir} , %{_datadir} , %{_libdir} , %{_sysconfdir} , %{_mandir} , %{_infodir} . Pour des jeux, utilisez %{_gamesbindir} et %{_gamesdatadir}


Section Changelog

%changelog

Cette section est destinée à garder une trace de tous les changements apportés au paquet. Chaque nouvelle version du paquet doit correspondre à un paragraphe de cette section ainsi qu’à une augmentation du numéro de version (si ce n’est pas le numéro de version). Ces paragraphes doivent respecter la structure suivante :


  • Mon Nov 02 2010 Camille Begnis <camille@mageia.org> 2.0.1-1mga1
  • La première ligne du paragraphe commence par * avec, dans l’ordre et séparés par un espace :
  • 3 lettres pour le jour de la semaine (en anglais)
  • 3 lettres pour le mois (en anglais)
  • 2 chiffres pour le jour du mois (en anglais)
  • 4 chiffres pour l’année
  • Prénom du créateur du paquetage
  • Nom du créateur du paquetage
  • courriel du créateur du paquetage entre <>.
  • version et release des modifications.
 - Upgraded to 2.0.1

Ensuite, une ligne, commençant par un -, par modification appliquée au paquetage.

Voici des exemples :

  • spec file stolen from korganizer.
  • last snapshot before release
  • Mageia adaptations.
  • Fix bug in /etc/zsh use USERNAME instead of USER.
  • Remove petit bouchon which annoys other players.
  • Improve /etc/z* to source the /etc/profile.d/ files.
  • fix typo in examples directory name
  • fixed QT libs version requirements
  • add patch to handle Earl Grey tea

Notez que par défaut que seules les entrées datant de moins d’un an seront préservés lors de la construction du paquet. Pour modifier ce comportement changez la valeur de la macro %_changelog_truncate

Le build

Notre fichier spec est enfin complet. Prenez une grande inspiration, asseyez vous et tapez rpmbuild -ba mypackage.spec.

On peut ajouter l’option --clean qui nettoie le répertoire BUILD une fois le paquetage construit. Pratique si vous manquez de place disque.

Vous allez voir apparaître toutes les commandes qu’il effectue pendant la construction. La toute dernière ligne donne le résultat :

Il y a alors deux possibilités pour la dernière ligne de votre processus :

  • 0.01% probabilities : + exit 0
  • 99.99% probabilities for other cases.

Si vous êtes dans le second cas, regardez les options de construction de RPM (man rpm) pour déboguer votre travail, regardez les fichiers spec d’autres personnes, etc.

Il y a une manière très propre de construire un paquetage : utilisez rpm -bs --rmspec --rmsource, pour supprimer tout ce qui provient de la construction d’origine, puis faites un rpm --rebuild.

Optimiser le build

Quand vous lancerez la commande pour construire le paquet, vous allez sans doute voir des messages comme "foo-devel is necessary for foo2".

Cela signifie qu’il manque des informations dans d’autres paquets utilisés pour la compilation (habituellement des fichiers du types foo.h). Si vous ne les avez pas, la compilation va s’arreter ou des fonctionnalités vont manquer dans votre paquet.

L’endoit où sont compilés les paquets officiels (le cluster de compilation Mageia) a déjà un grand nombre de ces paquets installés par les divers utilisateurs. Si un paquet est requis mais non déclaré dans votre fichier .spec, le paquet va compiler quand même. Cela fonctionnera, mais l’absence de ces informations empechera le build sur des machines n’ayant pas les packages devel non déclarés, rendant le debugage ou la mise à niveau plus difficile.

Pour trouver les paquets de développement nécessaires à la compilation d’un certain paquet, consultez le site Web du paquet, ou les fichiers README/INSTALL dans l’archive source. Généralement ces informations sont à un endroit ou à un autre (mais malheureusement pas toujours).

Une manière que rechercher ces « BuildRequires manquants » est de commencer l’empaquetage avec seulement les paquets « devel » de base installés :

  • glibc-devel
  • libncurses5-devel
  • libstdc++6-devel

Ensuite, installez seulement les paquets devel correspondant aux paquets demandés par la commande rpmbuild

Quand vous lancez le build, observez les messages « checking for… ».

Si vous voyez quelque chose comme « checking for foo…  foo.h not found », cela signifie que le header nécessaire n’a pas été trouvé sur votre système. Recherchez le paquet devel contenant « foo.h », mais soyez prudent : vous pouvez trouver plus d’un paquet contenant que vous cherchez. Dans ce cas, choisissez le paquet le plus évident. Ne choississez pas un paquet relatif au réseau quand vous buildez une application de son (par exemple).

Alors installez-le sur votre système, et n’oubliez pas d’ajouter son nom à la section BuildRequires de votre fichier SPEC.

Des headers manquants peuvent également être trouvés durant la compilation elle-même. Si elle s’arrête, rechercher d’autres éléments manquants "foo.h" et appliquer la même solution.

Vérifier et tester un RPM

Lire les pages Bugzilla pour en savoir plus sur le sujet.


Tests de base

Les premières étapes à faire sont :

  • Les RPM ont-ils été créés dans les bons dossiers avec des noms corrects ? (~/rpmbuild/SRPMS/ et ~/rpmbuild/RPMS/i586/).
  • Est-ce que les informations fournies par la commande rpm -qlivp --changelog mypackage.(src.)rpm sont correctes ?

Passer « rpmlint » sur le paquetage

On utilise ensuite le programme rpmlint, qui effectue des tests variés sur le paquetage. Vous pouvez obtenir un rapport sur le rpm spécifiée en tapant la commande :

Konsole.png
[user@computer ~]$ rpmlint mon_paquet.<archtype>.rpm

Pour plus de précisions, on peut y ajouter l’option -i. Vérifier le .rpm et le .src.rpm.

Vous pouvez configurer rpmlint] avec le fichier ~/.rpmilintrc ou /etc/rpmlintrc.

Vous devez définir au moins les suivantes :


from Config import *
setOption("Packager","login@email.org")
# default value
# setOption("Packager", 'Mageia Team <http://www.mageia.org>|@mageia.org')
addFilter("E : .* no-signature »)
addFilter(" W : .* invalid-packager »)
addFilter("E : .* no-packager-tag »)
addFilter("E : .*-debug .*")
addFilter("W : .*-debug .*")
# not very clean, but easier to maintain
release_tag = os.popen("rpm --eval '%mkrel 1'").readlines()[0][1:-1]
setOption("ReleaseExtension", release_tag)


Si vous avez l’intention de créer un rpm approprié pour l’inclure dans les répertoire de Mageia, vous devez également veiller à ce que « rpmlint-mageia-policy » soit installé, car il contient les différentes configurations et les politiques utilisés par les empaqueteurs de Mageia.

« rpmlint » va vérifier beaucoup de choses comme : tags, binaires, fichiers de configuration, l’emplacement, l’autorisation, la propriété, la conformité FHS, sources, menus, scripts, contenu du fichier de spec… Pour plus de détails consulter /usr/share/rpmlint/config.d/mageia.error.list.

Test d’installation

Sur une machine, si possible différente de celle sur laquelle a été faite la compilation, faites une mise à jour ou une installation et vérifiez si :

  • Tous les fichiers prévus ont-ils été créés au bon endroit avec les bons droits et les bons propriétaires ?
  • Toutes les modifications d’installation (s’il y en a) fonctionnent-elles ?
  • Tous les exécutables et la documentation sont-ils accessibles aux utilisateurs à qui ils sont destinés ?

Les perfectionnistes essaieront des installations et désinstallations diverses et variées pour vérifier que toutes les possibilités prévues sont correctement implémentées, par exemple quand il manque des paquetages requis.

Si tous ces tests ont été passés avec succès, c’est presque fini et on peut aller à la dernière étape du processus : distribuer le paquetage.

Quelque chose ne va pas ?

Bien, il semble que vous ayez lu ce tutoriel, c’est un bon début. Si vous ne trouvez pas votre réponse ici, vous pouvez toujours trouver plus d’informations.


Pour les généralités RPM

  1. Le RPM-HOWTO officiel (installé en même temps que le programme rpm sur votre système).
  2. Le livre « Maximum RPM », de Ed Bailey disponible sur [2].
  3. Poser une question sur la liste de diffusion à laquelle vous vous êtes inscrit récemment, au début de ce howto.

Pour des points plus spécifiques aux RPM Mageia :

Dites un mot à l’équipe Assurance Qualité de Mageia.

Si vous pensez que l’information que vous avez trouvée peut servir à d’autres, n’hésitez pas à la proposer au contributeur principal de ce document.


A propos des scripts de pré- et post-installation

Les bases

Un paquetage RPM est en fait bien plus qu’une simple archive contenant des fichiers à décompresser dans des répertoires spécifiques sur le système client.

Le système fournit au programmeur une possibilité intéressante : les scripts de pré- et post-installation. Grâce à eux, le créateur du paquetage peut écrire un morceau de code qui sera exécuté sur la machine cliente pendant l’installation ou la suppression du paquetage.

Il faut connaître certaines particularités de ces scripts pour en tenir compte : premièrement, ils doivent tenir dans une mémoire tampon de 8192 octets, deuxièmement, ils ne doivent pas être interactifs. Toute interaction avec l’utilisateur est à proscrire, puisqu’elle empêcherait les procédures automatiques d’installation de RPM de fonctionner.


Ces scripts se composent de n’importe quel ensemble de commandes sh valides. En voici quatre :

  • %pre : ce script s’exécute juste avant l’installation du paquetage sur le système.
  • %post : ce script s’exécute juste après l’installation du paquetage sur le système.
  • %preun : ce script s’exécute juste avant la désinstallation du paquetage du système.
  • %postun : ce script s’exécute juste après la désinstallation du paquetage du système.


Ces scripts ont un très grand rayon d’action et il faut les mettre au point avec le plus grand soin pour ne pas perturber le système hôte. Ne pas oublier que ces scripts s’exécuteront en tant que “root”… Ce sont les tâches système qu’un administrateur système accomplirait pour installer un nouveau programme sur le système. Par exemple :

  • Ajouter un job cron qui lance le programme à intervalles fixes.
  • Lancer chkconfig pour lancer le démon au moment du boot.

Gestion des mises à jour

Permettre la mise à jour, et pas seulement l’installation ou la désinstallation d’un paquetage complique un peu les choses… Le problème vient de ce que le script %postun de la mise à jour s’exécute après le script %post de la vieille version. Et tout ce que fait %post est perdu…

Il est souvent utile de vérifier qu’une action ne se produit que pendant l’installation et non pendant une mise à jour. De même pour une action qui ne se produit que pendant la désinstallation et non pendant une mise à jour. Le mécanisme de RPM qui gère cela est un argument passé aux scripts %pre, %preun, %post et %postun par défaut.

Cet argument indique le nombre d’instances de ce RPM qui seront installées sur la machine après l’exécution du script courant. Par exemple, si un nouveau paquetage est installé, 0 sera passé à %pre et 1 sera passé à %post. Quand le paquetage est mis à jour, 1 sera passé au %pre du nouveau RPM, 2 sera passé au %post du nouveau RPM, 2 sera passé au %preun de l’ancien RPM et 1 sera passé au %postun de l’ancien paquetage.

Paramètres / Script %pre %post %preun %postun
pour une première installation 1 1 N/C N/C
pour une mise à jour 2 2 1 1
pour une désinstallation N/C N/C 0 0

Le programmeur peut ainsi prévoir un fonctionnement différent de ses scripts selon qu’il s’agit d’une installation ou d’une mise à jour.

  • pour les scripts d’installation (%post, %pre) tester si $1 est égal à « 1 », ce qui signifie une première installation et non une mise à jour,
  • pour les scripts de désinstallation (%postun, %preun) tester si $1 est égal à « 0 », ce qui signe une suppression complète ; sinon, c’est soit une mise à jour soit un « install --force » du même paquetage.


Pour tester cet argument, on utilise la commande « if » suivante :

%postun
if [$1 = 0] ; then
// spécifique à la désinstallation
fi
if [$1 = 1] ; then
// spécifique à la mise à jour
fi

Un simple test suffit donc à appeler la bonne action au bon moment.

Filetriggers

rpm filetriggers (TODO) sont utilisés pour enlever la charge des tâches répétitives comme "%post -p /sbin/ldconfig » ou "%update_menus ».

D’autres macros

Pour construire des RPM pour Mageia, d’autres macros permettent de simplifier le fichier spec.

  • Gestion des pages info. Un exemple est le meilleur professeur :
%post
%__install_info %{name}.info

%preun
%__install_info %{name}.info
  • Gérer l'internationalisation proprement. La meilleure méthode n’est pas de créer à la main les fichiers .mo qui se trouvent en général dans /usr/share/locale/…, mais d’utiliser une macro spéciale de la section %install, qui remplira un fichier spécial pour cela :
%find_lang %{name}

On peut alors utiliser ce fichier dans la liste de fichiers :

%files -f %{name}.lang
  • Macros de construction. Les macros %configure et %makeinstall sont actuellement assez grosses. Elles précisent le préfixe, mais aussi les répertoires communs (comme bindir, datadir, etc.) ; moyennant cela, elles fonctionnent correctement avec des paquetages de taille moyenne, mais nécessitent toujours un peu d’attention pour les autres. La macro %make lance la commande make avec l’option -j appropriée pour bien fonctionner avec les multiprocesseurs. S’il faut appeler manuellement le script ./configure, se souvenir ne JAMAIS coder l’architecture en dur ; la macro %{_target_platform} est faite pour cela (ou même %{_target_cpu}, si nécessaire).
  • Construction de serveurs. Pour construire des serveurs plus sûrs, on utilise une macro spécifique, %serverbuild, à utiliser avant que le processus de build ne démarre. Elle permet de meilleures options d’optimisation. La section %build ressemble souvent à :
%build
%serverbuild
%configure
%make
  • Macros d’initialisation des scripts. Quand on installe un paquetage qui fournit son propre script d’initialisation (les fichiers du répertoire /etc/init.d), il faut les ajouter par un appel du style chkconfig --add .., sauf dans le cas des mises à jour, et il doit être redémarré s’il est en cours de fonctionnement ; en cas de désinstallation, il faut faire les actions inverses ; des macros spécifiques permettent cela sans peine :


%post
%_post_service <initscript-name>
%preun
%_preun_service <initscript-name>


  • Utilisation de fichiers fantômes. Certains paquetages, en particulier des jeux, utilisent parfois un fichier qui varie et qui peut même être absent. C’est ici que les fichiers fantômes sont utiles. Voici un exemple :
%install

(…)

mkdir -p $RPM_BUILD_ROOT/var/lib/games
touch $RPM_BUILD_ROOT/var/lib/games/methanescores

%post
%create_ghostfile /var/lib/games/powermanga.hi root games 664

(…)

%files
%attr(664, root, games) %ghost /var/lib/games/powermanga.hi

La macro %create_ghostfile se développe en :

if [! -f /var/lib/games/powermanga.hi] ; then
touch /var/lib/games/powermanga.hi
chown root.games /var/lib/games/powermanga.hi
chmod 664 /var/lib/games/powermanga.hi
fi

Vous pouvez aussi lister toutes les valeurs et les macros utilisées par rpm depuis les fichiers macros et rpmrc : rpm --showrc


Interaction avec urpmi et rpmdrake

Il faut parfois avertir l’utilisateur d’une précaution à prendre quand on met à jour ou qu’on installe une version particulière d’un paquetage. Les formats de nom de fichier suivants peuvent être utilisés :

  • README.install.urpmi n’est affiché que pour les paquetages installés ;
  • README.version.upgrade.urpmi et README.version.update.urpmi : Les affiches seulement pour les paquetages mis à jour ou mis à niveau ;

Sont aussi supportés README.urpmi (affiché dans les deux cas) et README.upgrade.urpmi/README.update.urpmi (toujours affiché lors d’une mise à niveau). Ceux-ci ne doivent pas être utilisés, car ils provoquent l’affichage du message à chaque mise à jour ultérieure, même si l’utilisateur a déjà vu le message à plusieurs reprises.

Tutoriel (exemple avec README.install.urpmi) :

  • Mettre README.install.urpmi dans le répertoire SOURCES/ ;
  • Ajouter dans le fichier spec comme « SourceX » : README.install.urpmi (remplacez X par un chiffre approprié) ;
  • Dans la section %install : installer -m644%{SourceX} README.install.urpmi (notez l’absence du préfixe %buildroot) ;
  • Dans la section %files : ajouter README.install.urpmi dans une macro %doc, ou ajouter une macro %doc si il n’y en a aucune.

Une alternative : checkinstall

Une autre façon vraiment simple de construire des RPM pour une utilisation personnelle est d’installer le paquet checkinstall ; de compiler la source comme d’habitude (./configure && make && sudo make install), mais en remplaçant make install par checkinstall. Ceci automatise la construction du RPM, tout en étant vraiment simple d’utilisation. L’avantage consiste dans le fait que vous ne contournez pas le manager RPM en compilant à partir des sources. (Cependant, si vous souhaitez distribuer vos RPM, il est fortement conseillé d’utiliser la méthode vue précédemment.)


Soumettre un paquet

Vous avez réussi à créer le paquet parfait d’un tout nouveau programme, et souhaitez le voir dans les dépôts officiels de Mageia, soumettez le à l’équipe des mainteneurs de Mageia.

Pour ça on utilise le système de rapport de bug de mageia : bugzilla.

Malheureusement, Bugzilla n’est pas disponible en français, inscrivez-vous | ici, avec une adresse courielle valide.

Créer un Rapport de bug

Faites « New », puis choisissez Mageia, ou rendez vous directement ici.

  • Mettez Component sur Nex RPM Package Request ;
  • Choisissez la Version ;
  • Choisissez le type d'architecture ;
  • Choisissez la Version ;
  • Remplissez le champs Source RPM ;
  • Remplissez Summary avec le nom du package.

Dans Details, entrez une description du programme (il est préalablement remplie pour vous aiguiller).

Envoyez le formulaire, laissez les autres champs vides, ce n’est pas nécessaire de les remplir. Ne cochez surtout pas les dernières cases, sinon votre rapport ne sera accessible qu’a très peu de personne, qui ne sont absolument pas concernées !


Alternative : alien

Les fichiers de spécifications (.spec) sont souvent empruntés à d’autres distributions Linux qui sont basées sur des rpms, telles que Fedora et vice versa. D’une manière similaire, mais plus souple, car la reconstruction de bibliothèques dépendantes pour une application spécifique peut s’avérer une tâche énorme, les auteurs de l’application originale peuvent fournir un binaire étranger en utilisant un système de paquets différent, comme Linux Standard Base (LSB-compliant.rpm), Debian (.deb), Stampede (.slp), Solaris (.pkg), par exemple. Dans ce cas, vous pouvez essayer d’utiliser « alien » pour convertir un système d’empaquetage vers un autre. Par exemple,« pandoc » est difficile à construire et à maintenir car c’est un « paquet Cabal » qui sera compilé avec « ghc » et de nombreuses bibliothèques Haskell, mais en utilisant alien, la ligne de commande : $ sudo alien --to-rpm --scripts pandoc-1.19.1-1-amd64.deb fournira un rpm binaire qui peut être installé par $ sudo rpm -ivh pandoc-1.19.1-2.x86_64.rpm et testé en convertissant un document LaTeX (.tex) en un document mediawiki (.wiki) : $ pandoc -o foo.wiki -f latex -t mediawiki foo.tex Le document MediaWiki produit sera compatible avec le wiki Mageia.