Empaquetage pour debutant-fr

Accueil [en] → Accueil → Équipes → Packageurs → Débuter

---

Pourquoi empaqueter ?

Les développeurs publient souvent leurs logiciels sur leurs site web et explique aux autres utilisateurs comment le compiler. Puis ils introduisent de nouvelles fonctionnalités, parfois optionnelles (qui ajoute plus de dépendances à d'autre logiciels), et comprendre la manière dont il faut le compiter devient de progressivement plus difficile. C'est ici que le role du mainteneur de paquet entre en compte. Dans une distribution binaire, nous empaquetons les programmes compilés, parfois séparés en plusieurs parties pour des fonctionnalités optionnelles. Comme ça, les utilisateurs n'ont plus qu'à installer le paquet, bien sûr si nous avons bien fait notre boulot, ça fonctionne.

Empaqueter n'est pas un boulot simple et le paquet viendra aussi paramétrer l'application d'une manière qui sera acceptable pour une majorité d'utilisateur, souvent de manière particulière pour une distribution GNU/Linux donnée. Ce qui signifie qu'il vaut mieux installer un paquet créer précisément pour votre distribution, si vous le pouvez.

Si vous souhaitez en savoir plus à propos de l'empaquetage voire comment empaqueter votre propre application, lisez la suite !

Comprendre l'empaquetage

De manière générale, empaqueter est le procédé d'automatisé les efforts de compilation, avec les liens vers les dépences etc. Effectivement, compiler une application et l'empaqueter avec tous ces scripts d'installation et d'autre informations prérequis pour l'installer sur votre système avec aucune connaissance spécialisé sur les logiciels.

Jargon

Dans l'ordre alphabétique :

arch	l'architecture du processeur, ex: i586 (32bit) ou x86_64 (64bit)
build	Le procédé de convertir un paquet source rpm (SRPM) en un paquet RPM installable.
buildrequires	Fichier de spécification contenant les mots clefs pour désigner les autres paquets nécessaire pour [construire] (build) un paquet. ex: les librairies gtk pour les programmes d'utilisateurs pour Gnome.
dependencies	Tous les paquets prérequis pour construire un paquet RPM (buildrequires), ou pour lancer un paquet RPM installé (compilé?) (requires).
desktop file	Un fichier formaté qui défini les entrées du menu.
patch	Un fichier qui liste les changements à appliquer à d'autres fichiers du SRPM pour résoudre des problèmes ou ajouter de nouvelles fonctionnalités.
provides	Fichier de spécification contenant les mots clefs pour des fonctions fournies par le paquet RPM, généralement le nom d'autres paquet RPM (souvent obsolète).
RPM	un type de paquet (originellement Redhat Package Manager, maintenant RPM package manager). Un fichier RPM contenant tout ce qui est nécessaire pour installer un logiciel en particulier. Il porte l'extension .RPM.
requires	Fichier de spécification contenant les mots clefs pour que le logiciel contenu dans le RPM fonctionne proprement.
spec	Le fichier .spec dans le SRPM contient des instructions pour savoir comment construire un ou plusieurs paquet RPM.
SRPM ou src.rpm	un paquet rpm source qui contient seulement les sources + les patches + le fichier .spec. Il est utilisé pour générer (build) un ou plusieurs fichier RPM installable.
suggests	Fichier de spécification contenant les mots clefs pour désigner d'autre paquet qui sont suggérés d'être installé avec ce paquet.
tarball	Une archive contenant les sources. Originalement c'était au format 'tar' (tape archive).
upstream	Le développeur actuel (généralement l'origina) du logiciel que vous empaqueter ou son site web.

Qu'y a t'il dans un paquet RPM ?

Habituellement une librairie, et/ou un programme, quelques documentations, parfois des manpages, etc...

Par exemple :

• /usr/lib64/libfoo.so
• /usr/bin/foo
• /usr/share/doc/foo/README
• /usr/share/man/man1/foo.1

Qu'y a t'il dans un paquet SRPM ?

Un SRPM est souvent fourni dans une archive .tar (autrement dénommé tarball), et un fichier de spécification, un éventuellement avec des patches, avec parfois des fichiers supplémentaires (par exemple un raccourci bureau ou des icones).

Par exemple :

• SPECS/foo.spec
• SOURCES/foo-2.3.5.tar.bz2
• SOURCES/foo-2.3.5-path-to-fix-specific-bug.patch
• SOURCES/foo.desktop
• SOURCES/foo.png

Bâcler : Comment faire un RPM depuis un SRPM

Un SRPM ne contient donc pas de programme compilé et ne devrait pas être dépendant d'une architecture, tandis que les RPM sont compilés et généralement dépendant d'une architecture spécifique.

rpmbuild --rebuild file.src.rpm

Ça n'installe pas les autres "buildrequires" (les dépendances), vous devez les installer manuellement.

Importantes choses à savoir

Le nom d'un fichier RPM a souvent cette allure ci : foo-2.3.5-2.mga7.x86_64.rpm avec :

• Nom : foo
• Version : 2.3.5
• Révision : 2
• Étiquette du SE : mga
• Version du SE : 7
• Architecture : x86_64
• Extension : rpm

Tandis que le nom d'un fichier SRPM a souvent cette allure là : foo-2.3.5-1.mga7.src.rpm avec :

• Nom : foo
• Version : 2.3.5
• Révision : 1
• Étiquette du SE : mga
• Version du SE : 7
• extension : src.rpm

(Ou vous pouvez vous dire que arch = src.)

Alors que le nom d'une archive upstream (venant du développeur) à cette allure là : foo-2.3.5.tar.bz2

• nom : foo
• version : 2.3.5
• extension : tar.bz2

Comme vous pouvez le voir, le nom et la version viennent directement du développeur, nous ne les modifions en aucun cas. La révision (release) est un numéro qui démarre à partir de 1 et s'incrémente si nous fournissons une mise à jours de la même version du logiciel.

un SRPM peut produire plus d'un RPM

Par exemple, un paquet foo-2.3.5-2.mga7.src.rpm peut produire :

• foo-2.3.5-2.mga7.x86_64.rpm : un paquet principal contenant des fichiers binaires.
• lib64foo2-2.3.5-2.mga7.x86_64.rpm : un paquet contenant une librairie requise.
• foo-data-2.3.5-2.mga7.noarch.rpm : un paquet indépendant de l'architecture qui contient des fichiers de données pour l'utilisation du paquet foo.
• foo-qt4-2.3.5-2.mga7.x86_64.rpm : un paquet optionnel pour un support sur Qt4 (KDE).
• foo-gtk-2.3.5-2.mga7.x86_64.rpm : un paquet optionnel pour un support sur GTK (Gnome).
• foo-devel-2.3.5-2.mga7.x86_64.rpm : un paquet contenant par exemple les fichiers d'entêtes (souvent des dépendances d'autres paquet peuvent être inclus dans ce fichier).
• foo-debug-2.3.5-2.mga7.x86_64.rpm : un paquet de débogage pour foo généré automatiquement.

Exemple A: façonner votre environnement et votre premier RPM

Bien voici une proposition :

• Commencer juste avec un paquet existant sur votre distribution (par exemple le dernier Mageia).
• Prennons, par exemple, "TeXworks" qui est un environnement de développement intégré pour LaTeX.

À partir de cette section, vous serait capable de :

• Vérifier si le logiciel est déjà empaqueté
• Obtenir un environnement d'empaquetage fonctionnel
• Créer un paquet qui se construit (build)
• Gagner en compréhension sur les dépendances et les prérequis (usant rpm, urpmq et comprendre la structure du répertoire)
• Créer un environnement local sur votre distribution courante pour empaqueter des logiciels.

La prochaine étape étant de le réviser et de le soumettre afin que vous puissiez obtenir un accès au système de construction (build-system) plus tard.

Tâches préliminaires

Veuillez suivre ce guide pour quelques tâches préliminaires.

Comprendre les .rpm et les src.rpm

À partir du nom de l'application "TeXworks" cherchez le nom du rpm :

• soit dans rpmdrake (il y a une barre de recherche)
  • vous devriez rapidement trouver que le nom du paquet est texworks
• soit utiliser urpmq (ou rpm is vous l'avez déjà installé) pour trouver des paquets avec des noms similaires :

urpmq -a -y TeX

• Si vous trouvez que le résultat est une longue liste de paquet ou aucun résultat, tentez de motifier la recherche pour être un peu plus précise ou plus complète :

urpmq -a -y works

Vous devriez être capable de trouver le fichier src.rpm :

• soit dans rpmdrake si vous avez configuré le dépôt src
• ou en tapant

  urpmq -i texworks

  dans un terminal. Utiliser les lignes de commandes n'est pas si difficile que ça ne le paraît et vous pouvez même copier-coller les commande de ce tutoriel pour simplifier les choses.
  • Considérons que vous avez trouvé Source RPM : texworks-0.6.1-3.mga7.src.rpm

Créer votre environnement d'empaquetage

Si vous essayez de reconstruire le paquet écrit en langage C vous aurez besoin d'installer le paquet task-c-devel. Si votre paquet est écrit en C++ vous aurez besoin d'installer le paquet task-c++-devel. L'installation d'un de ces paquets engendrera l'installation d'un certain nombre d'autre paquet.

Installez le paquet rpm-build :

[root@localhost ~]# urpmi rpm-build

Ça devrez tirer un tas de dépendances, répondez simplement "O" et laissez le tourner.

Vous pouvez aussi installer bm pour un gestionnaire de construction plus convivial.

Maintenant créez la structure du répertoire :

mkdir -p ~/rpmbuild/{SRPMS,SOURCES,SPECS,tmp}

Plus tard, lors de l'installation d'un paquet source (.src.rpm) ou de la construction d'un paquet, quelques répertoires seront créer ici comme BUILD, BUILDROOT et RPM.

Comprendre la structure de l'arborescence

Comme vous avez le nom du .src.rpm vous devriez pouvoir le télécharger depuis l'un des dépôts :

cd ~/rpmbuild/SRPMS

wget ftp://ftp.mirrorservice.org/pub/mageia/distrib/cauldron/SRPMS/core/release/texworks-0.6.1-3.mga7.src.rpm

urpmi texworks-0.6.1-3.mga7.src.rpm

Attention, les fichiers binaires ne sont pas réellement "installe"; il extrait les spécifications/archives et patches dans les répertoires appropriés.

Installer les dépendances de construction

La plus part des paquets dépendent d'autre paquets en quelques sens. Pour compiler un paquet, vous devez avoir les paquets dépendants installé. Dans la plus part des cas les paquets dépendants ont le suffixe -devel qui l'identifie comme une version de développement du paquet. Si un paquet prérequis n'est pas installé quand vous (re)construisez le paquet vous aurez un message d'échec identifiant la cause de l'erreur. Dans de nombreux cas le message d'erreur donnera explicitement quel paquet prérequis est manquant, mais parfois le message d'échec peut être particulièrement secret... Heureusement c'est assez facile d'installer tous les paquets nécessaire.

cd ~/rpmbuild/SPECS
su
urpmi texworks.spec
exit

La commande "su" (substitute user) vous permettra d'agir en tant que root, tandis que "urpmi nomdupaquet.spec" installera toutes les dépendances requises pour ce paquet. La commande exit vous remettra en tant qu'utilisateur normal.

(Re-)Construire votre src.rpm pour créer un rpm pour votre architecture

cd ~/rpmbuild/SPECS
rpmbuild -ba texworks.spec

Regardez dans ~/rpmbuild/RPMS/x86_64 (or i586 en fonction de votre architecture) : vous trouvez le paquet créé.

La commande

bm -l

reconstruira votre paquet si vous êtes dans son répertoire de base.

Exemple B: Mettre à jour un RPM existant à sa dernière version

Trouver la dernière version du logiciel

Prenons l'exemple ci dessus

• la commande "urpmq -i texworks" présente une ligne

  URL : http://www.tug.org/texworks/

• Vérifiez la dernière version (stable) disponible, le site web montre la version 0.6.2.

Prendre en compte la nouvelle version, construction

A partir de la section précédente, vous avez obtenu :

• un fichier .spec
• une archive tar
• peut-être quelques patches (vérifiez qu'ils ont été prix en compte en amont)
• (contenus et répertoires détaillés avec quelques explications)

Pour continuer,

• Faite juste les changements appropriés (mettez à jour le numéro de version et de la version du paquet dans le fichier spec, remplacez la dernière archive du répertoire SOURCES.
• et essayez de reconstruire avec la dernière version jusqu'à ce que plus aucune erreur ni avertissement aient été générées.
• enfin mettez à jour le .spec et lancez

  rpmbuild -ba texworks.spec

  jusqu'à ce que le fichier RPM soit créé.
• Ne pas oublié de faire un teste d'installation et assurez vous que ça fonctionne !