Red Hat Training

A Red Hat training course is available for Red Hat Satellite

Chapitre 3. Création de paquetages personnalisés

De nombreux aspects peuvent ne pas marcher dans la création de paquetages personnalisés, en particulier lorsque ces paquetages doivent être livrés et installés via Red Hat Network. Ce chapitre offre une vue d'ensemble sur la manière de créer des paquetages pour une livraison réussie via Red Hat Network. Parmi les sujets étudiés figurent pourquoi utiliser RPM, comment créer des paquetages pour RHN, et comment signer correctement des paquetages.

3.1. Construction de paquetages pour Red Hat Network

Red Hat Network utilise la technologie du Gestionnaire de paquetages RPM (RPM, de l'anglais RPM Package Manager) pour déterminer les ajouts et les mises à jour de logiciels applicables à chaque système client. Les paquetages obtenus de Red Hat Network sont normalement sous le format RPM. Les images ISO entières sont cependant disponibles via l'onglet Logiciels du site Web de Red Hat Network, mais elles ne sont pas disponibles dans les installations du RHN Satellite Server. Si le serveur Satellite a le support Solaris activé, vous pouvez utiliser l'outil RHN Push pour télécharger les paquetages Solaris vers les canaux personnalisés utilisés par les clients Solaris.
RPM est un outil qui offre aux utilisateurs une méthode simple pour installer, désinstaller, mettre à niveau et vérifier les paquetages logiciels. Il permet également aux développeurs de logiciels de mettre en paquetages le code source et les versions compilées d'un programme pour les utilisateurs et les développeurs.

3.1.1. Bénéfices de RPM

RPM offre les avantages suivants :
Mises à niveau faciles
À l'aide de RPM, vous mettez à niveau les composants individuels d'un système sans une réinstallation entière. Lorsque Red Hat publie une nouvelle version de Red Hat Enterprise Linux, les utilisateurs n'ont pas à effectuer une réinstallation pour mettre à niveau leur système. RPM permet des mises à niveau sur place, intelligentes et entièrement automatisées de votre système. Les fichiers de configuration dans les paquetages sont conservés afin que les utilisateurs ne perdent pas leurs personnalisations. Il n'existe pas de fichier spécial de mise à niveau nécessaire pour mettre à jour un paquetage vu que le même fichier RPM est utilisé pour installer et mettre à niveau le paquetage.
Interrogation de paquetages
RPM fournit des options d'interrogation qui vous permettent de rechercher dans votre base de données RPM tous les paquetages ou seulement certains fichiers. Vous pouvez également facilement trouver à quel paquetage appartient un fichier et d'où provient le paquetage. Les fichiers contenus dans le paquetage se trouvent dans une archive compressée, avec un en-tête binaire personnalisé contenant les informations utiles sur le paquetage et son contenu. RPM interroge les en-têtes d'une manière rapide et facile.
Vérification du système
Une autre fonction est la possibilité de vérifier les paquetages. Si vous pensez qu'un fichier associé à un paquetage a été supprimé, vous pouvez vérifier le paquetage pour voir le statut des fichiers qu'il fournit. La vérification vous avertit de toute anomalie. Si des erreurs existent, vous pouvez de nouveau facilement installer les fichiers. Les fichiers de configuration modifiés sont conservés durant la réinstallation.
Sources pristines
Un objectif crucial de la conception de RPM est de permettre l'utilisation de sources de logiciels pristines, comme elles sont distribuées par les auteurs des logiciels. Avec RPM, ces sources peuvent être mises en paquetages avec tout correctif qui était utilisé, plus des instructions complètes de création. Ceci est un avantage important pour plusieurs raisons. Par exemple, si une nouvelle version d'un programme est publiée, vous n'avez pas forcément à recommencer à zéro pour qu'il compile. Vous pouvez examiner le correctif pour voir ce que vous pourriez avoir à faire. Toutes les valeurs par défaut compilées et les changements apportés pour faire en sorte que le logiciel soit créé correctement, sont facilement visibles en utilisant cette technique.
Garder les sources pristines peut sembler important uniquement aux développeurs, mais le résultat est un logiciel de qualité supérieure pour les utilisateurs également.

3.1.2. Directives RPM de RHN

La force de RPM repose dans sa capacité de définir les dépendances et d'identifier des conflits correctement. Red Hat Network dépend de cet aspect de RPM. Red Hat Network offre un environnement automatisé, ce qui signifie qu'aucune intervention manuelle ne peut prendre place durant l'installation d'un paquetage. Ainsi, lors de la création de RPM pour la distribution via Red Hat Network, il est impératif de suivre les règles suivantes :
  1. Apprendre RPM. Il est crucial de posséder une compréhension profonde des fonctions importantes de RPM pour construire correctement des paquetages. Pour obtenir davantage d'informations sur RPM, commencez par les ressources suivantes :
  2. Lors de la construction d'un RPM enfant pour un canal enfant, créez le paquetage sur une installation fraîche de Red Hat Enterprise Linux de la même version que le canal de base de l'enfant. Assurez-vous d'appliquer tout d'abord toutes les mises à jour de Red Hat Network.
  3. Le paquetage RPM doit être installé sans l'utilisation des options --force ou --nodeps. Si vous ne pouvez pas installer un RPM proprement sur votre système construit, Red Hat Network ne peut pas l'installer automatiquement sur un système.
  4. Le nom de fichier du paquetage RPM doit être sous le format NVR (nom, version, publication) et doit contenir l'architecture pour le paquetage. Le format correct est nom-version-publication.arch.rpm. Par exemple, le nom de fichier d'un paquetage RPM valide est nompqtg-0.84-1.i386.rpm, où le nom est nompqtg, la version est 0.84, la publication est 1 et l'architecture est i386.
  5. Le paquetage RPM devrait être signé par le mainteneur du paquetage. Les paquetages non signés peuvent être distribués via Red Hat Network, mais yum doit être forcé à les accepter. Signer les paquetages est fortement recommandé et est examiné dans la Section 3.2, « Signatures numériques pour les paquetages RHN ».
  6. Si le paquetage est modifié d'une manière ou d'une autre, y compris changer la signature ou recompiler, la version ou la publication doit être augmentée de manière incrémentielle. En d'autres termes, le NVRA (y compris l'architecture) pour chaque RPM distribué via RHN doit correspondre à une construction unique pour éviter toute ambiguïté.
  7. Un paquetage RPM ne peut pas se rendre obsolète.
  8. Si un paquetage est divisé en paquetages séparés, faites extrêmement attention aux dépendances. Ne divisez pas un paquetage existant à moins d'avoir une très bonne raison de le faire.
  9. Aucun paquetage ne peut dépendre de scripts interactifs avant l'installation, après l'installation, avant la désinstallation ou après la désinstallation. Si le paquetage requiert une intervention directe de l'utilisateur durant l'installation, il ne peut pas fonctionner avec Red Hat Network.
  10. Tout script avant l'installation, après l'installation, avant la désinstallation et après la désinstallation ne devrait jamais écrire quoi que ce soit sur stderr ou stdout. Redirigez les messages dans /dev/null s'ils ne sont pas nécessaires. Sinon, écrivez les dans un fichier.
  11. Lors de la création du fichier de spécification, utilisez les définitions de groupes de /usr/share/doc/rpm-<version>/GROUPS. Si vous ne trouvez pas de correspondance exacte, sélectionnez la meilleure possible.
  12. Utilisez la fonction de dépendances RPM pour assurer que le programme soit exécuté après son installation.

Important

Ne créez pas un RPM en archivant les fichiers, puis en les désarchivant dans le script après l'installation. Cette action écrase l'objectif de RPM.
Si les fichiers de l'archive ne sont pas inclus dans la liste de fichiers, ils ne peuvent pas être vérifiés ou examinés contre tout conflit. Dans la plupart des cas, RPM peut tout même empaqueter ou désempaqueter des archives d'une manière très efficace. Par exemple, ne créez pas de fichiers dans une section %post que vous ne nettoyez pas dans une section %postun.