Un fichier RPM ne s’installe pas de la même façon sur Fedora, openSUSE ou Debian. Sur les distributions qui utilisent ce format, la méthode la plus sûre consiste généralement à passer par le gestionnaire de paquets de la distribution, comme dnf, yum ou zypper. Ces outils peuvent récupérer les dépendances manquantes et signaler les conflits avant de modifier le système. La commande rpm, elle, sert surtout à manipuler le paquet directement : pratique pour interroger son contenu ou vérifier une installation, moins confortable pour résoudre seul les dépendances.
Le format RPM est associé à Red Hat depuis les années 1990, mais son usage s’étend aujourd’hui à plusieurs familles Linux. Le fichier contient un logiciel et des métadonnées utiles à son installation, par exemple sa version, son architecture et les bibliothèques requises. Cela ne signifie pas qu’un RPM téléchargé au hasard fonctionnera partout : un paquet prévu pour Fedora peut dépendre de versions ou de chemins différents de ceux présents sur une autre distribution. Le nom du format ne garantit donc pas la compatibilité.
Ce guide distingue l’installation d’un logiciel depuis les dépôts de celle d’un fichier RPM local. Il présente les commandes adaptées aux principales distributions, les précautions à prendre avant d’exécuter une installation RPM et les solutions aux erreurs fréquentes. Le fil conducteur sera celui d’une petite équipe qui prépare un poste Linux pour un collègue : l’objectif n’est pas seulement de faire passer la commande, mais de pouvoir comprendre ce qu’elle change et revenir en arrière sans transformer la machine en puzzle.
En bref
- Privilégie le gestionnaire natif de ta distribution pour installer un fichier local.
- Sur Fedora, utilise généralement dnf install ./fichier.rpm.
- Sur les systèmes compatibles avec YUM, la commande prend la forme yum install ./fichier.rpm.
- La commande rpm n’installe pas automatiquement les dépendances manquantes.
- Sur Debian ou Ubuntu, un RPM n’est pas le format prévu pour le système : cherche plutôt un paquet DEB, Flatpak ou une autre méthode prise en charge.
Fichier RPM sous Linux : comprendre le paquet avant l’installation
Un fichier RPM est un paquet logiciel destiné aux distributions qui s’appuient sur l’écosystème RPM. Il peut contenir le programme, des fichiers de configuration, de la documentation et des informations de dépendance. Ces métadonnées indiquent notamment quelles bibliothèques ou quels composants doivent être présents pour que le logiciel puisse fonctionner.
Un paquet n’est pas simplement une archive que l’on décompresse dans un dossier au choix. Son installation inscrit des fichiers dans des emplacements attendus par le système et met à jour une base locale qui conserve la liste des logiciels installés. C’est cette base qui permet ensuite de connaître la version d’un programme, de le mettre à jour ou de le supprimer proprement.
La distribution reste le premier renseignement à vérifier. Fedora, Red Hat Enterprise Linux et certains de leurs dérivés utilisent RPM, tout comme openSUSE et Mageia. Debian, Ubuntu, Mint ou Kali reposent plutôt sur le format DEB et sur APT. Installer un paquet du mauvais format n’est pas une variante anodine : les chemins, les dépendances et les politiques de maintenance peuvent différer.
Un exemple concret : une petite agence veut installer un outil interne distribué sous forme de fichier RPM sur un poste Fedora. Le paquet a été conçu pour Fedora et correspond à l’architecture de la machine. L’installation peut alors s’intégrer aux mises à jour habituelles. Le même fichier copié sur une machine Ubuntu ne devient pas compatible par magie. Il vaut mieux demander au fournisseur un paquet DEB ou une version Flatpak plutôt que forcer la conversion.
Pour identifier le système avant toute manipulation, lance cat /etc/os-release. Le résultat indique le nom de la distribution et sa version. Pour connaître l’architecture du processeur, la commande uname -m renvoie par exemple x86_64 ou aarch64. Le paquet doit correspondre à cette architecture, sauf s’il est explicitement marqué comme indépendant de celle-ci.
RPM est aussi le nom de l’outil de bas niveau qui gère la base des paquets. L’historique explique pourquoi les termes se mélangent souvent : Red Hat a lancé le format au milieu des années 1990, puis plusieurs distributions l’ont adopté. Mais le format de paquet et l’outil qui télécharge les logiciels ne sont pas la même chose. Fedora s’appuie sur DNF, tandis que les systèmes SUSE utilisent Zypper, avec RPM en arrière-plan.
Les dépôts officiels restent le meilleur point de départ quand le logiciel y est disponible. Un dépôt fournit des paquets préparés pour une distribution et une version données ; le gestionnaire peut y vérifier les mises à jour et traiter les dépendances. Le fichier local répond à un autre besoin, par exemple lorsqu’un éditeur ne publie qu’un paquet téléchargeable ou qu’une version précise doit être installée pour un test.
À retenir : avant de chercher une commande, vérifie la distribution, la version, l’architecture et la provenance du paquet. Ces quatre éléments évitent une bonne partie des installations ratées.
Installation RPM en ligne de commande avec dnf, yum ou zypper
Sur Fedora, la commande habituelle pour installer un fichier local est sudo dnf install ./nom-du-paquet.rpm. Le préfixe ./ indique que le fichier se trouve dans le répertoire courant. DNF examine le paquet, résout les dépendances à partir des dépôts configurés, affiche les changements prévus et demande généralement une confirmation avant de les appliquer.
Si le fichier se trouve dans le dossier Téléchargements, indique son chemin, par exemple sudo dnf install ~/Téléchargements/outil.rpm. Il est possible de se placer d’abord dans le dossier avec cd ~/Téléchargements, puis de lancer la commande avec le nom du fichier. Cette petite précision sur le chemin évite une erreur classique : lancer l’installation depuis un répertoire où le paquet n’existe pas.
Sur les versions récentes de Red Hat Enterprise Linux et sur certains dérivés, yum peut rester disponible. La commande prend alors cette forme : sudo yum install ./outil.rpm. Dans les versions modernes, YUM repose souvent sur la technologie DNF ou agit comme une interface compatible. Sur des systèmes plus anciens, son comportement et ses options peuvent différer ; il faut donc suivre la documentation correspondant à la version installée plutôt que recopier une commande trouvée pour une autre génération.
Avec openSUSE, utilise Zypper et la commande sudo zypper install ./outil.rpm. Selon la version et la façon dont le fichier est référencé, Zypper peut présenter les dépendances à ajouter ou les conflits à résoudre. YaST propose aussi une interface graphique pour gérer les logiciels, pratique si tu préfères examiner les choix dans une fenêtre avant de confirmer.
Mageia possède ses propres outils, notamment urpmi en ligne de commande et l’interface graphique rpmdrake. Là encore, le bon réflexe est de privilégier l’outil natif de la distribution : il connaît ses dépôts, ses conventions et les versions de bibliothèques attendues. Un tutoriel qui conseille directement une commande RPM peut être pertinent pour un cas précis, mais ne constitue pas forcément la meilleure procédure pour une installation de tous les jours.
| Distribution ou famille | Outil conseillé | Exemple pour un fichier local |
|---|---|---|
| Fedora | DNF | sudo dnf install ./outil.rpm |
| RHEL et dérivés compatibles | YUM ou DNF selon la version | sudo yum install ./outil.rpm |
| openSUSE | Zypper | sudo zypper install ./outil.rpm |
| Mageia | URPMI ou rpmdrake | Consulter l’aide de la version installée |
Dans tous les cas, lis le récapitulatif affiché avant de valider. Il doit correspondre à ce que tu souhaites installer, sans supprimer des composants inattendus ni remplacer une pile logicielle entière. Pour un poste de travail partagé ou une machine de production, mieux vaut s’arrêter au moindre changement surprenant et comprendre la proposition avant de répondre oui.
Le gestionnaire natif n’est pas une simple commodité. Il garde l’installation cohérente avec la base de paquets et facilite les mises à jour ultérieures. Pour un poste de développeur qui reçoit régulièrement des correctifs, cette continuité vaut largement les quelques secondes gagnées avec une commande plus courte.
Installer un fichier RPM avec la commande rpm : quand l’utiliser
La commande rpm permet d’installer, de mettre à jour, de supprimer et d’interroger les paquets. Elle est utile pour inspecter un fichier ou vérifier l’état d’un logiciel. En revanche, elle ne remplace pas DNF, YUM ou Zypper pour résoudre les dépendances et télécharger les composants absents.
Pour installer directement un fichier, on rencontre souvent sudo rpm -i nom-du-paquet.rpm. L’option -i signifie installation. Pour mettre à jour un paquet déjà présent, la forme courante est sudo rpm -U nom-du-paquet.rpm ; l’option -U installe le paquet s’il n’existe pas encore ou le met à niveau s’il est déjà installé. Certains tutoriels ajoutent -v pour afficher plus d’informations et -h pour montrer une progression en caractères.
Cette méthode directe peut s’arrêter si une bibliothèque requise manque. Le message d’erreur ne signifie pas nécessairement que le fichier est endommagé : il peut simplement manquer un paquet dépendant, ou le fichier avoir été construit pour une autre version de la distribution. Télécharger cette bibliothèque séparément puis recommencer en chaîne devient vite pénible et peut créer des incompatibilités.
Pour obtenir des informations sur un paquet avant de l’installer, utilise rpm -qpi nom-du-paquet.rpm. Pour lister les fichiers qu’il contient, rpm -qlp nom-du-paquet.rpm interroge le fichier local. Une fois le logiciel installé, rpm -qi nom-du-paquet affiche les informations enregistrées et rpm -ql nom-du-paquet liste les fichiers associés.
La différence entre les options se voit dans la lettre p, qui indique que la commande vise un fichier de paquet, et non un paquet déjà enregistré dans la base système. C’est un détail facile à manquer quand on copie une commande depuis un forum. Pour supprimer un paquet installé, l’option -e est utilisée avec son nom enregistré : sudo rpm -e nom-du-paquet. Il ne faut généralement pas saisir le nom complet du fichier RPM à cette étape.
Un scénario raisonnable pour employer RPM directement : un administrateur doit inspecter les métadonnées d’un paquet téléchargé sur une machine isolée, ou vérifier quels fichiers une installation a déposés. Pour installer le logiciel sur une machine connectée, l’outil de la distribution reste préférable. Cette séparation est saine : RPM fournit le mécanisme bas niveau, tandis que le gestionnaire de paquets orchestre les dépôts, les dépendances et les transactions.
Si tu veux comprendre les outils de prise en main à distance avant de configurer une machine Linux, tu peux aussi consulter ce retour sur l’installation et l’usage de RustDesk. Il ne remplace pas les procédures de paquets, mais illustre bien une autre question pratique : vérifier la compatibilité d’un logiciel avec son environnement avant de le déployer.
Sur une machine de test, comparer le résultat d’une installation avec la liste des fichiers déclarés par le paquet aide à comprendre ce qui a changé. Sur un serveur, en revanche, éviter les opérations directes non suivies est une règle de prudence : il faut savoir quelle version est installée, d’où elle vient et comment la mettre à jour ensuite.
Position pratique : utilise RPM pour inspecter et diagnostiquer ; pour installer au quotidien, laisse DNF, YUM ou Zypper gérer la transaction complète.
RPM sur Debian, Ubuntu et les autres distributions Linux
Debian, Ubuntu, Linux Mint et leurs dérivés utilisent principalement des paquets DEB gérés par APT. Un fichier RPM n’est donc pas le format natif de ces systèmes. La commande sudo apt install ./paquet.deb ne peut pas installer un RPM, et renommer le fichier en changeant son extension ne transforme pas son contenu.
Des outils comme alien peuvent convertir certains paquets RPM en DEB. Cette conversion reste une solution de dernier recours, pas une garantie de fonctionnement. Elle ne traduit pas automatiquement les scripts d’installation, les dépendances propres à la distribution ni les différences de structure du système. Un paquet converti peut s’installer puis échouer au lancement, ou écraser des fichiers attendus par un autre composant.
Avant de convertir, cherche une version conçue pour ta distribution. Le site de l’éditeur peut proposer un dépôt APT ou un paquet DEB. Pour un logiciel graphique diffusé sans paquet natif, Flatpak peut être une option plus cohérente, à condition que l’application soit disponible sur une source reconnue et que ses permissions correspondent à ton usage. Pour un outil serveur, vérifie plutôt les instructions officielles et les méthodes de déploiement prises en charge.
Cette logique s’applique aussi aux familles qui ont leurs propres gestionnaires. Arch Linux et Manjaro utilisent pacman ; Gentoo s’appuie sur Portage et la commande emerge ; Slackware distribue notamment des archives TXZ et fournit installpkg. Ces formats ne sont pas interchangeables avec RPM. Le paquet doit être pensé pour les conventions et les bibliothèques du système ciblé.
Un exemple : une développeuse télécharge un RPM pour un navigateur, puis tente de le déployer sur Ubuntu parce que le site de l’éditeur ne présentait pas immédiatement le bon format. La meilleure étape n’est pas de forcer la conversion, mais de vérifier les autres canaux de distribution proposés par l’éditeur. Pour choisir un navigateur adapté à une machine Linux, ce guide sur les navigateurs disponibles sous Linux peut aussi aider à repérer une version prévue pour la distribution concernée.
Les solutions universelles ne sont pas toutes équivalentes. Flatpak vise les applications de bureau et isole une partie de leur environnement ; les paquets natifs s’intègrent plus étroitement aux outils du système. Le choix dépend du logiciel, de la politique de la machine et de la manière dont les mises à jour sont administrées. Pour un serveur, installer un format de bureau « universel » n’est pas automatiquement la bonne réponse.
Il existe aussi des situations où aucun paquet approprié n’est fourni. Compiler depuis les sources est alors possible, mais cela demande de vérifier les instructions du projet, les dépendances de compilation et la méthode de désinstallation. Une compilation manuelle peut laisser des fichiers hors de la base du gestionnaire : il faut documenter l’emplacement choisi, ou utiliser les outils de construction prévus par le projet.
Forcer l’installation d’un RPM sur une distribution non compatible fait gagner peu de temps si l’application ne peut ensuite ni se mettre à jour proprement ni être supprimée sans laisser de traces. Le bon format est celui que la distribution sait maintenir, pas celui dont l’extension paraît familière.
Dépendances, signatures et erreurs fréquentes pendant l’installation RPM
Une erreur de dépendance indique qu’un composant requis est absent ou qu’une version installée ne correspond pas à celle attendue. Avec DNF, YUM ou Zypper, commence par relancer l’installation via le gestionnaire natif et examine les dépôts configurés. Il peut trouver le composant automatiquement. Si aucun paquet compatible n’est disponible, le fichier RPM ne vise peut-être pas ta distribution ou sa version.
Évite de télécharger à la main une série de bibliothèques depuis des sites tiers pour satisfaire chaque message d’erreur. Cette approche peut installer des versions contradictoires ou des fichiers qui ne seront jamais suivis par le système. Si une dépendance manque sur une distribution d’entreprise, vérifie d’abord les dépôts activés et les instructions du fournisseur du logiciel.
Un conflit de fichiers mérite aussi une pause. Il peut signifier qu’un autre paquet possède déjà le même chemin, ou que le RPM tente de remplacer une version installée par une source différente. N’utilise pas une option qui force l’écrasement avant d’avoir identifié le paquet propriétaire et la raison du conflit. Sur une machine partagée, cette vérification évite de casser un logiciel qui semblait sans rapport.
La provenance compte autant que la commande. Télécharge le paquet depuis le site de l’éditeur ou un dépôt reconnu, puis vérifie la somme de contrôle si elle est publiée. La commande sha256sum nom-du-paquet.rpm calcule une empreinte locale ; compare-la à celle fournie par la source officielle. Une empreinte identique confirme que le fichier reçu correspond à la valeur annoncée, sans prouver à elle seule que l’éditeur est digne de confiance.
Les signatures cryptographiques apportent un autre contrôle : elles servent à vérifier que le paquet a été signé par une clé reconnue et n’a pas été modifié depuis. Ne contourne pas un avertissement de signature uniquement pour faire disparaître le message. Pour un paquet fourni par une entreprise, demande la clé ou la procédure de vérification officielle, puis vérifie que la source correspond bien au fournisseur attendu.
Avant l’installation, examine aussi le nom complet du fichier. Il contient souvent le numéro de version, la version de publication et l’architecture. Un nom terminé par x86_64 n’est pas destiné à une machine ARM, tandis qu’un paquet marqué noarch ne dépend généralement pas d’une architecture particulière. Cette indication ne suffit pas à garantir la compatibilité, mais elle permet d’éliminer rapidement une erreur évidente.
- Confirme la distribution et sa version avec cat /etc/os-release.
- Vérifie l’architecture avec uname -m et lis le nom du paquet.
- Contrôle la provenance, la somme de contrôle et la signature lorsqu’elles sont disponibles.
- Installe avec le gestionnaire natif et lis la liste des changements avant confirmation.
- Après l’opération, vérifie la version installée et la disponibilité d’une mise à jour.
Une fois l’installation terminée, interroge la base avec la commande adaptée, par exemple rpm -qi nom-du-paquet, ou utilise le gestionnaire natif pour confirmer que le logiciel est enregistré. Lance ensuite l’application ou son service et consulte ses journaux si le démarrage échoue. Une installation qui se termine sans erreur ne garantit pas que le programme dispose de tous les réglages nécessaires.
Quand le paquet vient d’un éditeur externe, clarifie aussi sa méthode de mise à jour. Certains logiciels ajoutent un dépôt ; d’autres demandent de télécharger chaque nouvelle version. Sans cette étape, un outil installé manuellement peut rester bloqué sur une version ancienne alors que le reste du système reçoit ses correctifs.
Quelle commande utiliser pour installer un fichier RPM sur Fedora ?
Utilise généralement sudo dnf install ./nom-du-paquet.rpm. DNF peut résoudre les dépendances depuis les dépôts configurés et affiche les changements avant de les appliquer.
Peut-on installer un RPM avec la commande rpm directement ?
Oui. La forme courante est sudo rpm -i nom-du-paquet.rpm, mais RPM ne récupère pas automatiquement les dépendances manquantes. Pour une installation ordinaire, DNF, YUM ou Zypper est généralement préférable.
Un fichier RPM peut-il être installé sur Ubuntu ou Debian ?
Ce n’est pas le format natif de ces distributions. Cherche un paquet DEB, un dépôt APT ou une version Flatpak. La conversion d’un RPM peut échouer à cause des dépendances et des différences propres au système.
Comment vérifier le contenu d’un fichier RPM sans l’installer ?
La commande rpm -qpi nom-du-paquet.rpm affiche ses métadonnées, tandis que rpm -qlp nom-du-paquet.rpm liste les fichiers qu’il contient.
