Un package est une archive contenant des données et/ou des programmes ainsi que les informations nécessaires à une installation correcte de ceux-ci sur le système. Un package est constitué d'un et un seul fichier, ce n'est pas un exécutable, il est pris en charge par un programme dédié, le gestionnaire de package.
Il existe plusieurs types différents de package
La gestion des dépendances est un des gros avantages des systèmes de packages.
Chaque package contient une liste des fonctionnalités qu'il fournit, cela commence par le nom du package lui-même, cela peut également être un programme particulier, une bibliothèque générique ou dans une version plus particulière ou encore une fonctionnalité plus ``diffuse'' telle que ``serveur ftp'' pour apache ou ``gestionnaire de téléchargement'' pour wget.
Ensuite les packages vont contenir une liste des fonctionnalités qui leurs sont nécessaires pour être fonctionnels2.
Lors de l'installation, le gestionnaire de packages va vérifier que toutes les dépendances sont vérifiées et que l'installation du nouveau package ne va pas écraser des fichiers d'autres packages, sinon il refusera d'installer, il reste possible de forcer l'installation à ses risques et périls.
De même, à la désinstallation d'un package, il vérifie que la suppression de ce(s) package(s) ne gène pas le fonctionnement d'autres packages, une fois encore on peut ne pas tenir compte des dépendances mais cela peut s'avérer assez grave (forcer la désinstallation de la glibc est le parfait exemple de ce qu'il faut faire si on veut foutre en l'air son système).
Si pour installer une documentation il est suffisant d'en décompresser les fichiers, il n'en va pas forcément de même pour des programmes et encore moins pour des bibliothèques dont l'installation nécessitera d'effectuer des opérations sur le systèmes pour que le contenu du package soit pleinement fonctionnel.
C'est à cela que servent les scripts d'installation/désinstallation qui se présentent sous la forme de simples scripts shell (au standard sh). Ils sont au nombre de quatre
Beaucoup de distributions utilisent le système RPM, l'organisation
des packages n'est pas cohérente entre les différentes distributions
(par exemple entre RedHat et SuSe), il faut donc être prudent si l'on
veut installer un package n'ayant pas été prévu spécifiquement pour
sa distribution, il convient alors de vérifier si les dépendances
correspondent, si les lieux d'installation sont adéquats et si les
scripts sont adaptés au système.
Si les dépendances ne sont pas nommées de la même façon mais sont
présentes on peut forcer l'installation sans vérification des dépendances
(en les ayant d'abord toutes vérifiées).
Si l'emplacement des fichiers est inadéquat, certains packages (suivant
la façon dont ils ont été construits) permettent la relocalisation
de ses fichiers.
Si les scripts ne sont pas adaptés on peut effectuer l'installation
sans exécuter les scripts puis faire toutes les démarches à la main.
Il existe des outils permettant de convertir des packages d'un format vers un autre (par exemple alien qui fait le lien entre les types rpm et deb), ces outils doivent être pris comme des pis-aller car, les différents types ne gérant pas les choses de la même façon (voir carrément pas les mêmes choses), le package converti ne sera jamais aussi bon qu'un package natif.
Nous allons suivre les étapes de la réalisation d'un package RPM simple (une application), l'exemple retenu est le programme ksetiwatch (http://ksetiwatch.sourceforge.net/), il va de soi qu'avant d'entreprendre la réalisation du package il faut vérifier que toutes les bibliothèques et programmes nécessaires au programme sont bien présents sur le système et que le programme se compile correctement, cela permet également de repérer des options de compilation utiles.
Maintenant que nous savons que notre programme compile, nous pouvons envisager de la packager.
Vérifions tout d'abord la configuration de rpm à l'aide de la commande
À partir d'ici les répertoires relatifs sont des sous-répertoires de %_topdir.
Plaçons l'archive dans RPM/SOURCES et créons un fichier ksetiwatch.spec dans RPM/SPECS, ce fichier spec va contenir toutes les informations de création du package.
On commence par définir quelques macros qui simplifierons l'écriture de la suite du specfile et la mise à jour du package vers une version plus récente
Buildroot: /tmp/ksetiwatch-%ver
%description
This is Ksetiwatch 2.2.5, a monitoring tool and work unit manager for the SETI@home project. It is designed for KDE 2.x and Qt 2.2.x or higher. Ksetiwatch provides the look-and-feel of the popular SETIWatch program for Windows95/98/NT, written by Mark Loukko (http://members.home.net/mloukko/SETI.html).
L'entrée Source spécifie le nom de l' (des) archive(s) ou se trouvent les sources du programme, celle(s)-ci sera décompressée dans RPM/BUILD.
L'entrée Buildroot indique ou le programme devra être temporairement installé avant de réunir ses fichiers dans le package, on utilise ici un sous-répertoire du répertoire temporaire du système, /tmp.
Les autres entrées sont auto-explicites.
%setup -n ksetiwatch-%{ver}
%build
./configure -prefix=$RPM_BUILD_ROOT%{prefix}
make all
%build est l'étape à laquelle le programme va être compilé, on effectue d'abord le classique ./configure en utilisant le répertoire temporaire précédemment défini ainsi qu'un préfixe (ici /usr), puis le make all qui lance la compilation.
%postun
if [ -x /usr/bin/update-menus ]; then /usr/bin/update-menus || true ; fi
La compilation s'effectue simplement avec
Un package source se créera simplement avec la commande
Copyright (c) Renaud Michel.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation.