Un plugin indispensable pour la gestion des commentaires d’un blog, une brique de sécurité fournie uniquement en RPM, un agent de supervision à déployer en urgence… Sur un serveur Linux, ce scénario revient souvent. Dès qu’un éditeur cible les distributions de la famille Red Hat, il fournit en priorité un paquet RPM. Comprendre comment installer proprement un RPM sous Linux, selon la distribution et le contexte, évite les bricolages hasardeux dans le terminal et limite les plantages en pleine charge. L’enjeu n’est pas seulement de lancer une commande, mais de garder un système cohérent, capable d’encaisser les futures mises à jour sans se transformer en Frankenstein logiciel.
Derrière un simple fichier .rpm se cache tout un écosystème de gestionnaire de paquets, de dépôts et de dépendances. Fedora, RHEL, CentOS Stream, Alma, Rocky, openSUSE ou SLES ne traitent pas tous un RPM de la même façon. Certains privilégient dnf, d’autres gardent encore yum dans les scripts anciens, d’autres enfin misent sur zypper. Selon que le paquet provient d’un dépôt officiel, d’un éditeur tiers ou d’un partage interne, la stratégie d’installation ne sera pas la même. Un administrateur qui sait naviguer entre rpm, dnf, yum et zypper gagne en autonomie et réduit le temps passé à courir après des bibliothèques manquantes.
En bref
- Un fichier RPM est le format de paquet des distributions Red Hat, Fedora, CentOS, Alma/Rocky, SUSE et dérivées, pensé pour la gestion centralisée des logiciels.
- La bonne méthode d’installation dépend de la distribution Linux et du contexte : rpm direct, dnf/yum sur RHEL/Fedora, zypper sur openSUSE/SLES.
- Les gestionnaires de paquets gèrent automatiquement les dépendances et les mises à jour, contrairement à rpm utilisé seul.
- Vérifier l’intégrité et la signature GPG du RPM limite les risques de corruption ou de paquet compromis.
- Savoir désinstaller et nettoyer les paquets évite les bibliothèques orphelines et maintient un système stable pour les futures installations.
Installer un RPM sur les distributions Red Hat, CentOS, Alma, Rocky : choisir entre rpm, yum et dnf
Quand un administrateur tombe sur un fichier nommé tree-1.6.0-10.el7.x86_64.rpm dans un répertoire de téléchargement, plusieurs indices sont déjà là. Le suffixe .el7 signale un paquet prévu pour RHEL 7 et ses clones, tandis que x86_64 indique l’architecture AMD64/Intel 64. Avant même de lancer une commande d’installation, vérifier que ce RPM colle bien à la version de la distribution évite une bonne partie des erreurs de compatibilité. Installer un RPM de RHEL 7 sur une RHEL 9 ou une AlmaLinux récente est rarement une bonne idée.
Les distributions de la famille Red Hat partagent le même socle technique, mais pas toujours les mêmes outils par défaut. Sur RHEL 8/9, AlmaLinux ou Rocky Linux, dnf est devenu le gestionnaire de paquets recommandé. Sur d’anciennes CentOS ou RHEL 7, c’est encore yum qui reste très présent, même si dnf peut parfois cohabiter. Dans tous les cas, la commande rpm reste la brique de base pour manipuler le format, interroger la base locale ou vérifier un paquet, mais ce n’est pas l’outil à privilégier pour une installation de production.
Une erreur fréquente consiste à installer systématiquement via rpm -ivh fichier.rpm parce que « ça marche ». Cette approche court-circuite la résolution automatique des dépendances. Concrètement, si le plugin de commentaires d’un blog dépend d’un module PHP supplémentaire ou d’une bibliothèque système, rpm se contentera de signaler une erreur de type « missing dependencies » et s’arrêtera. Dnf, lui, ira chercher les paquets requis dans les dépôts configurés et proposera une installation complète.
Pour un serveur type RHEL/Alma/Rocky, la séquence logique ressemble à ceci dans le terminal :
1. Vérifier que le paquet est ce qu’il prétend être, par exemple avec sha256sum ou la vérification de signature GPG intégrée à rpm.
2. Lister les informations du RPM sans l’installer avec rpm -qpi paquet.rpm afin de vérifier le résumé, la version, l’architecture et les dépendances déclarées.
3. Passer l’installation à dnf install paquet.rpm, qui se chargera de récupérer les bibliothèques manquantes.
Pour une brique critique comme un serveur web ou un module de sécurité, cette discipline fait la différence entre un déploiement propre et une compilation sauvage de bibliothèques à la main. À l’inverse, il existe quelques cas où la commande rpm reste plus directe, par exemple pour interroger la base des paquets avec rpm -qa ou pour vérifier rapidement un paquet installé via rpm -V. Ces commandes ne changent rien au système tant qu’aucune option d’installation n’est ajoutée.
Un détail souvent négligé concerne l’option -U de rpm. Sur un serveur applicatif classique, utiliser rpm -Uvh paquet.rpm pour tout, sauf le noyau, reste cohérent : la commande installe le paquet s’il n’est pas présent, ou le met à jour s’il existe déjà. Par contre, sur tout ce qui touche au kernel, mieux vaut garder rpm -ivh pour installer un noyau supplémentaire sans écraser l’ancien. Une mise à jour ratée de noyau peut rendre un serveur incapable de démarrer, ce qui est moins drôle en prod qu’en homelab.
Pour comparer rapidement les grandes méthodes sur ces distributions, un tableau aide à trancher selon la situation.
| Outil | Usage recommandé | Gestion des dépendances | Remarques pratiques |
|---|---|---|---|
| rpm | Interrogation, vérification, installations ponctuelles très contrôlées | Manuelle uniquement | À réserver aux cas où le comportement doit être totalement explicite |
| yum | CentOS/RHEL 7 et environnements anciens | Automatique depuis les dépôts configurés | Encore très présent dans les scripts historiques et documentations anciennes |
| dnf | Fedora, RHEL/Alma/Rocky récents | Automatique, plus robuste sur les conflits | Comportement plus prévisible sur les dépendances complexes |
Au final, sur cette famille de distributions, installer un RPM sans exploiter dnf ou yum revient à se priver volontairement du pilote automatique. Pour un blog de production ou une plateforme métier, ce choix finit presque toujours par se payer un jour ou l’autre, généralement pendant une fenêtre de maintenance trop courte.
Installer un RPM local avec dnf ou yum sur un serveur applicatif
Prenons un exemple concret avec une PME qui héberge son blog et un outil de tickets sur un même serveur AlmaLinux. L’éditeur de l’outil de tickets fournit un RPM nommé supportdesk-2.4.1-1.el9.x86_64.rpm. L’admin transfère le fichier via scp, puis se rend dans le répertoire cible. À ce stade, deux commandes suffisent dans le terminal :
dnf install ./supportdesk-2.4.1-1.el9.x86_64.rpm
puis, plus tard, pour une nouvelle version, un simple dnf update ./supportdesk-2.5.0-1.el9.x86_64.rpm.
Dnf détecte automatiquement que le paquet installé est plus ancien et gère la mise à jour, tout en conservant les fichiers de configuration modifiés sous des noms de type .rpmsave ou .rpmnew. Le détail à surveiller ensuite consiste à fusionner ces fichiers pour ne pas perdre un paramètre de sécurité ou un réglage de performance ajusté à la main.
Certains administrateurs préfèrent garder la main sur leurs scripts. Pour déployer plusieurs RPM de plugins sur une grappe de serveurs, un petit script bash peut boucler sur une liste de fichiers et appeler dnf à la chaîne. Le gain est clair pour un blog multi-noeuds ou une ferme de serveurs web : une commande orchestrée par SSH ou Ansible, et tous les noeuds reçoivent la même version du logiciel.
Quand on commence à empiler ce type de mécanisme, un rappel s’impose : installer un RPM par copie manuelle reste acceptable pour quelques paquets bien identifiés. Au-delà, mieux vaut réfléchir à un dépôt interne ou à des solutions plus structurées qu’un dossier partagé rempli de RPM disparates.
Installer un RPM sur Fedora, openSUSE et SLES : dnf, zypper et particularités des distributions
Sur Fedora, les réflexes sont proches de ceux d’Alma ou Rocky, mais avec quelques spécificités utiles, surtout pour un poste de développement ou un serveur applicatif moderne. L’outil par défaut est dnf, et les RPM tiers sont souvent fournis pour la dernière ou l’avant-dernière version de la distribution. Pour installer un codec multimédia ou un plugin spécifique utilisé par un blog de démonstration, il est courant de s’appuyer sur le dépôt RPM Fusion, accessible via un RPM de configuration.
L’installation de RPM Fusion se fait, par exemple, avec :
sudo dnf install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm
puis, si besoin, la variante non libre pour certains codecs. Une fois ce RPM de configuration en place, la plupart des paquets s’installent ensuite via une simple commande dnf install sans manipulation manuelle de fichiers. Pour un créateur de contenu qui publie des tutoriels vidéo sous Linux, cette approche évite d’aller chasser chaque RPM à la main.
De son côté, le monde SUSE mise sur zypper. Sur openSUSE Leap ou Tumbleweed, un RPM obtenu depuis un site tiers s’installe typiquement via zypper install fichier.rpm. Zypper gère les dépendances de façon similaire à dnf, mais ses commandes et sa manière d’afficher les conflits changent légèrement. Sur un serveur SLES hébergeant un blog d’entreprise, un administrateur qui alterne entre RHEL et SUSE doit s’habituer à ces nuances pour éviter de confondre les options.
Un point intéressant avec openSUSE réside dans l’écosystème d’outils et de distributions. Par exemple, certains environnements plus atypiques, présentés sur des ressources comme cet article sur une distribution Linux alternative, peuvent s’appuyer sur des paquets RPM tout en ayant leur propre logique de dépôts. Cela démontre que le format RPM dépasse largement le seul cadre Red Hat.
Entre Fedora et openSUSE, la philosophie de mise à jour diverge aussi. Fedora suit un rythme de release très dynamique, avec des évolutions de bibliothèques fréquentes. Installer un RPM prévu pour Fedora 39 sur une Fedora 41 n’est pas garanti, même si l’architecture reste la même. Les erreurs de dépendances sont alors fréquentes, et le réflexe devrait être de chercher une version du paquet adaptée à la release exacte plutôt que de forcer l’installation.
Sur SUSE, certains environnements serveurs restent très conservateurs : un paquet prévu pour SLES 15 ne se transplante pas sans réfléchir sur une openSUSE Tumbleweed en rolling release. Là aussi, la compatibilité affichée dans le nom de fichier du RPM doit être lue comme un contrat : plus on s’en éloigne, plus le risque de casse augmente. Installer un RPM « parce qu’il passe » en ignorant ces signaux revient à poser une bombe à retardement dans la pile logicielle.
Dans ce paysage, la meilleure approche reste toujours la même : privilégier les dépôts officiels ou bien intégrés à la distribution, n’utiliser l’installation de RPM isolés que lorsque c’est nécessaire, et garder un oeil sur la cohérence globale des versions de bibliothèques.
Cas pratique : ajouter un plugin tiers pour un blog sur Fedora
Imaginons un blog technique qui tourne sur Fedora Server avec un CMS moderne. L’équipe souhaite tester un module de statistiques avancées fourni uniquement en RPM par l’éditeur. Le fichier téléchargé affiche un nom du type cms-stats-1.3.2-2.fc40.x86_64.rpm. La présence de fc40 montre la cible Fedora 40. Sur un serveur déjà passé sur Fedora 41, deux options se présentent.
Soit attendre que l’éditeur publie une version compatible, démarche la plus saine. Soit tenter l’installation en surveillant de très près les dépendances. Dnf affichera rapidement si des bibliothèques sont trop anciennes ou trop récentes. En cas de conflits, la tentation peut être forte d’ajouter des options de type –skip-broken ou de forcer l’installation via rpm. C’est précisément là que le système commence à se désynchroniser.
Si, malgré tout, l’équipe choisit de tenter le coup pour un environnement de test, la bonne pratique consiste à enclencher quelques garde-fous : snapshot de la VM, sauvegarde de la base de données du blog, et suivi des paquets installés via dnf history. Cela permet de revenir en arrière proprement si le module se met à provoquer des erreurs PHP ou des conflits avec d’autres plugins. Installer un RPM n’est pas qu’un acte ponctuel, c’est une modification durable de la chaîne logicielle.
Sur SUSE, la scène est proche. Un module .rpm est fourni pour SLES 15 SP4 et installé via zypper, mais le blog tourne sur une openSUSE plus récente. Plutôt que de forcer, un administrateur expérimenté commencera par vérifier l’existence d’un dépôt adapté, voire envisagera de reconstruire le RPM pour sa cible, ce qui mène à la question de la création de paquets personnalisés.
Maîtriser rpm en ligne de commande : interrogation, vérification, installation contrôlée
Au-delà des gestionnaires de paquets haut niveau, la commande rpm elle-même reste un outil de diagnostic précieux. Elle sait installer, désinstaller, mettre à jour, vérifier et interroger. Pour un blog hébergé depuis plusieurs années sur un même serveur, cette capacité à auditer ce qui a été installé d’origine et ce qui a été modifié aide à comprendre pourquoi certaines mises à jour se passent bien et d’autres déclenchent des comportements étranges.
Un bon réflexe consiste à utiliser rpm pour comprendre avant d’installer. Avec rpm -qpi fichier.rpm, il devient possible de lire la description, la version, l’architecture et les dépendances déclarées du paquet sans aller plus loin. Sur un gros plugin de CMS, cette commande permet déjà d’anticiper la présence de bibliothèques graphiques inutiles sur un serveur sans interface, ou de dépendances vers des versions précises de PHP.
Une autre commande utile est rpm -ql paquet, qui liste tous les fichiers installés par un paquet donné. Quand un module de blog installe des fichiers un peu partout dans /usr/lib, /etc ou /var, cette liste devient un guide précieux pour nettoyer correctement en cas de désinstallation ou de rollback, au lieu de supprimer au hasard des répertoires dans le système de fichiers.
La vérification via rpm -V paquet mérite aussi d’être mieux connue. Elle compare l’état actuel des fichiers installés avec les métadonnées d’origine stockées dans la base RPM. Si un fichier de configuration a été modifié, un code comme c apparaît, et certains indicateurs signalent des changements de taille, de checksum ou de permissions. Sur un serveur qui a subi de multiples interventions dans le temps, cette commande aide à identifier les paquets les plus touchés par des modifications manuelles.
Sur le volet installation, rpm expose plusieurs options qui attirent beaucoup trop les débutants : –force, –nodeps, –replacefiles, –oldpackage. Toutes ces options ont un usage légitime en cas d’urgence ou pour des cas de support bien documentés, mais les employer de manière systématique finit toujours par casser la cohérence du système. Installer un RPM en forçant, puis découvrir deux mois plus tard que la mise à jour automatique échoue à cause de conflits internes, c’est une scène récurrente dans les environnements mal gérés.
Pour illustrer l’usage contrôlé de rpm, un scénario utile consiste à « rafraîchir » des paquets téléchargés. Avec rpm -Fvh *.rpm dans un répertoire rempli de paquets, rpm mettra à jour uniquement les paquets déjà installés, sans ajouter de nouveaux logiciels. Ce comportement se révèle pratique pour appliquer un lot de correctifs à un environnement de test, tout en évitant de charger le système avec des services inconnus.
On pourrait résumer les bonnes pratiques autour de rpm ainsi :
- Interroger d’abord avec rpm -q, -qi, -ql et -V pour comprendre l’état actuel.
- Installer via le gestionnaire de paquets (dnf, yum, zypper) pour profiter de la résolution de dépendances.
- N’utiliser rpm en installation directe que pour des cas maîtrisés, idéalement en labo ou avec un plan de retour en arrière.
Ce trio de réflexes évite de transformer la base RPM en puzzle, tout en donnant à l’administrateur un niveau de visibilité que les simples commandes dnf install n’offrent pas toujours.
Gérer les dépendances, les dépôts et la sécurité lors de l’installation d’un RPM
Le coeur des problèmes liés au format RPM ne vient pas du format lui-même, mais des dépendances. Chaque paquet indique ce dont il a besoin pour fonctionner : bibliothèques partagées, services annexes, versions minimales de composants clés. Quand tout provient de dépôts cohérents, le gestionnaire de paquets s’en sort bien. Dès que l’on mélange des dépôts de provenances différentes ou des RPM téléchargés à droite et à gauche, les ennuis commencent.
Sur un serveur Linux qui héberge un blog et quelques services annexes, la gestion des dépôts devient une question stratégique. Activer tous les dépôts possibles pour « tout avoir » mène directement aux conflits de versions. À l’inverse, rester collé uniquement aux dépôts de base oblige parfois à renoncer à certains plugins ou outils. Le juste milieu consiste à limiter le nombre de dépôts tiers, à documenter pourquoi chacun a été ajouté, et à favoriser des sources reconnues comme RPM Fusion pour Fedora ou des dépôts partenaires dans l’écosystème Red Hat.
Avant même d’installer, la question de l’origine du RPM se pose. Pour un plugin de commentaires, télécharger le fichier directement sur le site officiel de l’éditeur reste la base. Un miroir inconnu ou un lien partagé sur un forum représente un risque inutile, même si le fichier porte le bon nom. Les commandes md5sum ou sha256sum permettent de vérifier l’intégrité du fichier en comparant l’empreinte affichée avec celle fournie par l’éditeur.
La sécurité ne s’arrête pas là. Les signatures GPG intégrées aux RPM jouent un rôle clé. Lors d’une installation avec rpm ou dnf, si la clé publique de l’éditeur n’est pas installée, un avertissement de type NOKEY apparaît. Sur un serveur sensible, ignorer ce message n’est pas acceptable. Importer la clé GPG officielle, vérifier sa provenance, puis relancer l’installation donne au moins l’assurance que le paquet provient bien de l’entité attendue.
Sur le plan pratique, plusieurs sources de documentation aident à monter en compétences sur ces sujets. Pour ceux qui aiment explorer des distributions plus confidentielles ou des OS spécialisés, des ressources comme un guide dédié à une distribution Linux orientée mobile rappellent à quel point les chaînes de paquets et les signatures évoluent selon les contextes. Là où un serveur RHEL suit une politique stricte, un environnement expérimental peut tolérer davantage d’approches manuelles, à condition de rester maîtrisé.
Dans les environnements professionnels, ignorer un conflit de dépendances en utilisant –nodeps ou en mélangeant des dépôts hétérogènes revient souvent à déporter le problème dans le futur. Le jour où une mise à jour de sécurité critique doit s’installer rapidement, le gestionnaire de paquets se retrouve coincé par des versions hybrides impossibles à concilier. Les quelques minutes gagnées au moment de l’installation initiale se transforment alors en heures de reprise manuelle.
Dépannage des erreurs courantes liées aux RPM
Malgré toutes les précautions, quelques messages d’erreur reviennent souvent. L’un des plus courants, « package is already installed », apparaît lorsqu’un RPM portant le même nom et la même version est déjà là. Dans ce cas, plusieurs options existent : vérifier si une version plus récente est disponible, désinstaller proprement l’ancienne, ou réinstaller le même paquet en utilisant –replacepkgs si des fichiers ont été supprimés à la main.
Une autre erreur fréquente concerne les conflits de fichiers : « conflicts with file from package ». Deux paquets tentent d’installer le même fichier dans le système de fichiers. Sans recul, l’option –replacefiles peut sembler tentante, mais le risque de casser l’autre paquet reste bien réel. Une analyse plus fine implique de déterminer quel paquet doit être considéré comme la source légitime du fichier, parfois en se référant à la documentation des deux logiciels ou en vérifiant quels services dépendent réellement de ce fichier.
Les cas de dépendances non résolues sont aussi très fréquents. Là, les commandes dnf provides, yum provides ou zypper search deviennent essentielles. Elles permettent d’identifier quel paquet propose une bibliothèque manquante et d’intégrer son installation dans le même cycle. En dernier recours, télécharger manuellement toutes les dépendances depuis des sources tierces reste possible, mais le jeu n’en vaut presque jamais la chandelle pour des systèmes de production.
Pour garder un cap clair, une petite checklist peut servir de garde-fou :
- Contrôler les droits administrateur avant toute installation de RPM.
- Vérifier l’empreinte du fichier téléchargé et, si possible, la signature GPG.
- Analyser le message d’erreur au lieu de le contourner systématiquement avec des options de force.
- Limiter les dépôts actifs et documenter ceux qui sortent du socle officiel.
En suivant cette logique, installer un RPM reste un acte maîtrisé, même en cas d’urgence ou de demande métier pressante.
Installer, désinstaller et automatiser les RPM dans un environnement serveur
Une fois les bases posées, la vraie vie d’un serveur Linux ne se limite pas à installer. Les paquets tournent, vieillissent, se mettent à jour, puis finissent parfois par devenir inutiles. Pour un blog qui vit plusieurs années, les modules changent, certains plugins sont remplacés, d’autres disparaissent. Savoir désinstaller proprement les RPM et nettoyer les dépendances inutiles est aussi important que maîtriser l’installation initiale.
Sur la ligne de commande, la désinstallation directe via rpm -e nom_du_paquet fonctionne, à condition d’utiliser le nom du paquet et non celui du fichier .rpm. La commande rpm -qa permet d’obtenir la liste des paquets installés, parfois combinée à un grep pour retrouver un plugin spécifique. Mais, comme pour l’installation, la méthode recommandée reste de passer par le gestionnaire de paquets : dnf remove, yum remove, zypper remove.
L’avantage est double. D’abord, ces outils vérifient les dépendances à la désinstallation, pour éviter de supprimer un paquet encore nécessaire à un autre. Ensuite, ils proposent souvent une commande de nettoyage comme dnf autoremove ou yum autoremove, capable d’éliminer les bibliothèques devenues orphelines suite à la suppression d’un gros module. Sur le long terme, ce nettoyage limite l’encombrement disque et réduit la surface d’attaque potentielle.
Sur les environnements plus élaborés, l’automatisation de l’installation de RPM devient presque incontournable. Qu’il s’agisse de déployer un même module de blog sur dix serveurs ou de propager un agent de supervision, il est souvent plus rentable de rédiger un script shell ou d’utiliser un outil d’orchestration plutôt que de se connecter à la main sur chaque machine. Un simple script qui boucle sur une liste de fichiers RPM et appelle dnf install -y apporte déjà un gain de temps significatif.
Pour aller plus loin, certains choisissent de créer un dépôt RPM interne. Tous les paquets, qu’ils proviennent d’éditeurs tiers ou de développements maison, y sont regroupés. Les serveurs n’ont plus qu’à pointer vers ce dépôt via leur gestionnaire de paquets, ce qui permet de piloter les installations et mises à jour de façon beaucoup plus prévisible. Dans ce modèle, installer un plugin de blog, un driver spécifique ou un agent de monitoring se fait avec une simple commande dnf install, sans transfert manuel de fichiers.
Un autre axe de professionnalisation consiste à construire ses propres RPM. Au lieu de déposer un script bash dans /usr/local/bin et d’espérer que tout le monde l’installe correctement, packager l’outil sous forme de RPM avec un fichier spec bien renseigné offre plusieurs avantages : gestion des dépendances, désinstallation propre, versionnement clair, et intégration possible dans des dépôts internes. Pour un outil maison utilisé par plusieurs équipes, c’est souvent la frontière entre « script perso » et véritable composant de l’infrastructure.
À la fin, installer un RPM sous Linux, selon la distribution et le contexte, devient un geste presque routinier. La différence entre un environnement sain et un système bancal repose surtout sur les habitudes prises autour de ce geste : utilisation raisonnée des gestionnaires de paquets, respect de la cohérence des versions, contrôle des dépôts et automatisation réfléchie.
Comment savoir si un fichier RPM est compatible avec ma distribution Linux ?
Regardez d’abord le nom complet du fichier RPM : il contient souvent un indicateur de version de distribution, par exemple el7 pour RHEL/CentOS 7, el9 pour RHEL 9 ou fc40 pour Fedora 40. Vérifiez aussi l’architecture, comme x86_64 pour les systèmes 64 bits classiques. Pour un doute persistant, utilisez la commande rpm -qpi fichier.rpm pour lire les informations internes et comparez avec la version exacte de votre distribution (sortie de cat /etc/os-release).
Faut-il utiliser rpm ou le gestionnaire de paquets pour installer un RPM ?
Pour la plupart des cas, mieux vaut passer par le gestionnaire de paquets natif de la distribution (dnf, yum, zypper). Ces outils résolvent automatiquement les dépendances, prennent en compte les dépôts configurés et gèrent mieux les mises à jour. La commande rpm est idéale pour interroger, vérifier ou analyser un paquet, et pour des installations très contrôlées en environnement de test, mais n’est pas le meilleur choix pour la gestion courante des logiciels.
Que faire en cas d’erreur de dépendances lors de l’installation d’un RPM ?
Évitez de contourner le problème avec –nodeps. Commencez par lire attentivement le message d’erreur, qui indique quels paquets ou fichiers manquent. Utilisez ensuite dnf provides, yum provides ou zypper search pour identifier les paquets qui fournissent ces fichiers, et installez-les via le gestionnaire de paquets. Si le paquet dépend d’une version précise d’une bibliothèque absente de votre distribution, vérifiez si l’éditeur propose une version du RPM adaptée à votre version de système.
Comment désinstaller proprement un paquet RPM devenu inutile ?
La méthode la plus propre consiste à utiliser dnf remove, yum remove ou zypper remove avec le nom du paquet. Le gestionnaire de paquets se charge de vérifier les dépendances et évite de supprimer un composant encore nécessaire à d’autres logiciels. Après la désinstallation, exécutez éventuellement dnf autoremove ou l’équivalent pour nettoyer les bibliothèques orphelines. Réservez rpm -e aux cas particuliers ou à des environnements de test.
Est-ce risqué d’installer un RPM téléchargé depuis un site tiers ?
Le risque dépend largement de la source. Pour limiter les problèmes, ne téléchargez des RPM que depuis les sites officiels des éditeurs ou des dépôts reconnus. Vérifiez l’empreinte du fichier avec sha256sum et, si possible, la signature GPG. En cas de doute, abstenez-vous ou testez le paquet dans un environnement isolé (machine virtuelle, conteneur) avant de l’installer sur un serveur de production.
