Création du programme d'installation en RPM

Usage du RPM

Définition

Le RPM ( Redhat Package Manager ) est le gestionnaire de paquetages ( à l'origine, il a été crée pour les distributions Redhat ) , il peut être utilisé sur plusieurs distributions différentes.

Propriétées

le RPM permet l'installation de programme qui sont contenus dans des paquetages.il favorise la mise à jour du systeme. Quelques commandes simples facilitent aussi la desinstallation et la mise à jour des paquetages RPM. RPM entretient une base de donnees des paquetages installés et de leurs fichiers, ce qui nous permet de procéder à des recherches et des vérifications dans notre système.
Le RPM manipule les fichiers de configuration avec soin durant les mises à jour afin d'éviter que nos personnalisations ne soient perdues (chose qu'on ne pourrait faire avec des fichiers au format .tar.gz).
Pour un developpeur, le RPM lui permet de prendre le code source du logiciel et de le transformer en paquetage source et binaire pour l'utilisateur à la fin. C'est ce que nous allons vous montrer dans les lignes suivantes.

Création d'un RPM

Introduction

Le processus qui conduit à la création d'un RPM est piloté par un seul fichier qu'on appelle le Spec file et des patchs facultatifs que l'on crée. Le principe suit plusiers étapes.
Pour la création des RPMS, on se sert de 5 principaux répertoires:

• SOURCES: qui contient les sources du logiciel compressé dans un .tar.gz
• SPECS: contient le fichier .spec qui permet de construire le RPM.
• BUILD: lieu où sera decompresse le .tar.gz et la compilation du programme
• RPMS: contient les binaires du RPM construit.

Création du spec file

On commence par créer un fichier .spec dans le répertoire SPECS. Dans ce fichier, on définit les principales propriétées de constitution du RPM en plusieurs phases:

• Définition :
  cette phase contient les principaux champs qui définissent le RPM comme par exemple Name qui contient le nom du paquetage, Version la version du paquetage installé, Description la présentation du contenu du paquetage.
• La phase Prep :
  cette partie represente la phase durant laquelle le fichier.tar.gz sera décompressé dans le répertoire BUILD. Ceci peut se faire à travers une macro predefinie appelée par
• La phase Build :
  ce passage permet de compiler les sources du logiciel . Cette étape peut etre simplifiée par la construction d'un makefile et l'appel de la commande make.
• La phase Install
  cette partie represente la phase qui permet d'installer les binaires et la doc du logiciel dans les répertoires correspondants. On utilise aussi bien un fichier install pour cette phase s'il a été crée.
• La phase Files
  cette partie définie les fichiers ( binaires et documents ) qui seront insérés dans le paquetage en suivant les chemins définis dans la phase Install.
• La phase Clean
  cette étape est la dernière executee dans la construction d'un paquetage RPM. On peut y inserer les commandes permettant d'effacer les fichiers crées pendant la construction du RPM.

Construction du RPM

Après avoir créé le fichier .spec, on se positionne dans le répertoire SPECS. On tape la commande rpm -ba fichier.spec. Elle permet de contruire le paquetage rpm qui se trouve dans le répertoire RPMS (pour le paquetage contenant que le binaire et la doc) et dans le répertoire SRPMS (pour le paquetage qui contient les sources du logiciel) .

Objectifs de la création de RPM

La conception des RPM a de nombreux objectifs :

• Evolutivite : il permet de mettre à jour les composants du système sans avoir à tout réinstaller.
• Facilitation de la recherche: il donne la possibilité de rechercher dans la base de données des paquetages un fichiers spécifiques par exemples.
• Vérification du système: il permet de vérifier si un fichier est bien présent dans un paquetage . On peut alors le réinstaller si le fichier n'est pas present.
• Sources d'origine : le RPM donne la possibilite de modifier les sources d'un logiciel afin d'y rajouter de nouvelles fonctionnalitées (pour un développeur par exemple).

Conclusion

Ignorant tout de ce qu'était l'analyse du signal, ce projet avait la paricularité de nous plonger dans un univers inconnu. Pourtant, après un an de recherche et de travail, Marvin est utilisable, et même si son aspect et surtout son principe de fonctionnement sont loin de ce que nous avions imaginé en début d'année, sa finalité reste identique.

Maintenant, l'objectif qui nous tiens particulièrement à coeur, c'est d'éviter que Marvin tombe dans la désuétude en continuant de le faire vivre sur le net sous une licence GPL.
(http://themarvinproject.free.fr/)

Bibliographie

[BEN 92] Y. Bennani-Meziane : Approches connexionistes pour la reconnaissance automatique du locuteur, modélisation et identification, ANRT-Grenoble.

[CHA 96] I. Charon, A. Germa, O. Hudry : Méthodes d'optimisation combinatoires, Collection Pédagogique de Télécommunication MASSON.

[KUN 93] S. Y. Kung : Digital Neural Network. PTR Prentice Hall Englewood Cliffs, New Jersey 07632, 1993.

The Handbook of Brain Theory, M.I.T. Press.