Quand un développeur ou un admin télécharge un logiciel pour Linux, il tombe encore très souvent sur un fichier tar.gz plutôt qu’un package DEB ou RPM. Ce format regroupe une archive tar et une compression gzip, pratique pour diffuser des sources ou des binaires sur toutes les distributions. Le revers, c’est que sans méthode claire, la phase d’installation en ligne de commande tourne vite au copier-coller hasardeux. L’objectif ici est simple : passer d’un fichier téléchargé à un binaire fonctionnel dans le PATH, sans casser le système et sans perdre de temps à chaque mise à jour.
Sur le terrain, les équipes se retrouvent souvent avec un tarball venu d’un éditeur, d’un GitHub ou d’un fournisseur industriel qui ne propose pas de package natif. C’est le cas typique d’un outil de supervision, d’un driver ou d’un collecteur de métriques livré seulement en tar.gz. Malik, administrateur dans une PME industrielle, a par exemple dû intégrer un agent de monitoring distribué uniquement sous cette forme sur une dizaine de serveurs. En structurant la procédure autour de quelques réflexes simples – emplacement des sources, lecture des fichiers README/INSTALL, gestion des dépendances et choix du préfixe d’installation –, il a pu standardiser sa méthode et documenter un pas-à-pas réutilisable par toute l’équipe. Ce guide reprend ce type d’approche concrète : des commandes reproductibles, des points de vigilance, et quelques désaccords assumés avec certaines mauvaises habitudes bien ancrées.
En bref
- Un fichier tar.gz est une archive tar compressée avec gzip, fréquente pour distribuer des sources sous Linux.
- L’extraction de base se fait avec tar -xvzf fichier.tar.gz dans un terminal, depuis le répertoire de téléchargement.
- Avant de compiler et installer, la lecture des fichiers README et INSTALL reste non négociable pour comprendre les options et les dépendances.
- La séquence classique reste : ./configure, puis make, puis éventuellement sudo make install, en vérifiant où vont les fichiers.
- Pour des usages récurrents en prod, mieux vaut encapsuler l’installation dans un package natif ou un script, plutôt que d’empiler les make install sur plusieurs serveurs.
Fichier tar.gz sous Linux : comprendre ce que l’on installe réellement
Un fichier tar.gz combine deux couches : une archive créée avec tar (regroupement de fichiers et répertoires), puis une compression avec gzip. Sous Linux, ce format sert surtout à diffuser des sources de programmes ou des binaires « bruts », sans intégration profonde avec le gestionnaire de packages de la distribution.
Concrètement, l’archive peut contenir du code source en C/C++, Rust, Go, des scripts, de la documentation, parfois même des binaires déjà compilés. Sans ouverture préalable, difficile de savoir si l’on va lancer une simple commande ou déclencher une chaîne de compilation. C’est précisément ce flou qui explique tant d’installations « magiques » suivies d’environnements impossibles à auditer.
Premier réflexe donc : traiter un tar.gz comme une boîte noire qui doit être inspectée avant toute installation. Ce n’est pas une simple archive de sauvegarde, c’est potentiellement un morceau d’infrastructure qui va vivre des années sur un serveur.
Extraction d’un fichier tar.gz en ligne de commande : les options tar à connaître
Pour extraire un fichier tar.gz sous Linux, la commande de base reste la même sur Ubuntu, Debian, Fedora ou Arch. Depuis le répertoire où se trouve l’archive, dans un terminal :
Commande type :
tar -xvzf fichier.tar.gz
Les options clés méritent d’être comprises, car elles reviennent partout :
- -x indique à tar qu’il faut extraire.
- -v affiche le détail des fichiers traités, utile pour vérifier le contenu.
- -z signale une compression gzip (.tar.gz, .tgz).
- -f précise que l’argument suivant est le nom du fichier.
Pour un .tar.bz2, on remplace simplement -z par -j : tar -xvjf fichier.tar.bz2. Certains admins préfèrent aussi prévisualiser le contenu avant d’extraire, avec tar -tzf fichier.tar.gz. C’est une bonne habitude pour repérer la structure du répertoire racine et éviter d’inonder le mauvais dossier.
Pour ceux qui veulent aller plus loin sur la compression, les commandes gzip et les variantes modernes comme zstd sont détaillées dans ce guide dédié : gzip sous Linux et commandes associées. Mieux maîtriser ces briques de base rend la manipulation d’archives beaucoup plus sereine.
Installer un fichier tar.gz sous Linux : séquence type depuis le terminal
Une fois l’extraction faite, la vraie question commence : comment installer ce qui vient d’être décompressé sur le système ? Sur la plupart des logiciels distribués en source, la séquence est toujours la même, même si chaque projet ajoute parfois sa couche de spécificités.
Dans l’exemple de Malik, l’agent de supervision livré en tar.gz contenait un script configure classique et un Makefile. Il a pu s’aligner sur cette séquence standard, valable pour 80 % des projets encore basés sur autotools.
De l’extraction à l’installation : commandes pas à pas
Une procédure type pour installer un package livré en tar.gz peut se résumer ainsi :
- Se placer dans le répertoire de téléchargement : cd ~/Téléchargements.
- Extraire l’archive : tar -xvzf monlogiciel-1.2.3.tar.gz.
- Entrer dans le répertoire créé : cd monlogiciel-1.2.3.
- Lire les fichiers README et INSTALL.
- Lancer la configuration : ./configure (éventuellement avec des options).
- Compiler : make.
- Tester l’installation simulée : make -n install pour voir où tout va se poser.
- Installer réellement : sudo make install si le projet le recommande.
Cette séquence peut sembler un peu verbeuse pour qui vient d’un monde « tout package ». Mais elle a un avantage net : on voit exactement ce qui arrive sur la machine, et où. Ignorer l’étape make -n install revient à signer un chèque en blanc à un script inconnu, ce qui n’est pas vraiment aligné avec les exigences actuelles de traçabilité.
Choisir où décompresser et installer le tar.gz : organisation et préfixe
Un autre point souvent négligé concerne le rangement. Lancer un tar -xvzf dans n’importe quel dossier finit forcément par créer une arborescence illisible, surtout sur un serveur qui vit longtemps. La plupart des équipes structurées réservent quelques répertoires bien identifiés pour les sources et les logiciels compilés à la main.
Une approche assez répandue consiste à stocker les archives et sources dans /usr/local/src pour les applications, et /usr/src pour les composants plus proches du système (noyau, toolchain). Certains vont plus loin et organisent encore ces répertoires par lettres initiales ou par fournisseurs, histoire de retrouver en quelques secondes d’où vient un binaire installé il y a trois ans.
Le rôle de ./configure et du préfixe d’installation
La commande ./configure prépare le terrain : elle détecte les dépendances, vérifie la présence des bibliothèques nécessaires et génère un Makefile adapté à la machine. C’est aussi ici qu’on choisit le préfixe d’installation, c’est-à-dire la racine où le logiciel viendra s’installer.
Deux choix dominent :
- –prefix=/usr/local (souvent par défaut) : les binaires vont dans /usr/local/bin, les configs dans /usr/local/etc, etc. C’est idéal pour distinguer ce qui vient du système de ce qui a été ajouté à la main.
- –prefix=/usr : intégration plus « native », mais au risque de se confondre avec les paquets de la distribution. À réserver aux cas où l’on sait vraiment ce que l’on fait.
Une commande type devient alors :
./configure –prefix=/usr/local –sysconfdir=/etc –localstatedir=/var
Cette combinaison a un mérite : elle respecte l’arborescence classique /etc pour les configs et /var pour les données variables, tout en isolant les binaires non gérés par le gestionnaire de packages. Ce compromis convient bien aux PME industrielles qui veulent garder la main sans transformer chaque serveur en maquette d’école d’ingé.
Avant de lancer make : vérification des dépendances et pièges fréquents
Le moment où tout casse, pour beaucoup, c’est la compilation. Un make qui s’arrête sur une bibliothèque manquante ou une version trop ancienne peut être décourageant. Pourtant, 80 % des erreurs auraient pu être évitées avec une simple lecture des fichiers fournis par le projet.
Premier avis tranché ici : ignorer les fichiers README et INSTALL est une mauvaise idée. On y trouve souvent la liste des dépendances à installer via apt, dnf ou pacman, avec les noms précis des paquets de développement (les fameux *-dev ou *-devel).
Check-list rapide avant compilation
Une petite liste de vérifications avant de lancer make évite pas mal de perte de temps :
- Confirmer que le compilateur (souvent gcc ou clang) est installé.
- Installer les en-têtes et bibliothèques indiqués dans le README (par exemple libssl-dev, libcurl4-openssl-dev).
- Vérifier les versions minimales de certaines dépendances, surtout sur des distributions plus anciennes.
- Se demander si le serveur concerné doit vraiment compiler, ou si un binaire déjà compilé ailleurs serait plus pertinent.
Une remarque au passage : si la compilation échoue systématiquement, il est parfois plus raisonnable de chercher un package déjà préparé pour votre distribution, ou un conteneur adapté, plutôt que d’insister. La productivité ne se mesure pas en heures passées à se battre avec un configure obsolète.
Pour ceux qui basculent régulièrement entre Linux et Windows, un point de comparaison intéressant est ce guide sur les différences entre Windows 10 et 11, qui rappelle à quel point la gestion des logiciels reste différente selon les systèmes. Sous Linux, la liberté de compiler s’accompagne forcément d’un petit effort de discipline.
Tableau récapitulatif : commandes clés pour installer un fichier tar.gz
Pour garder sous la main les commandes essentielles liées aux archives tar et à leur installation, le tableau suivant sert de pense-bête. Il ne remplace pas la documentation spécifique de chaque projet, mais offre une base commune pour tous les tarball classiques.
| Étape | Commande ou action | Remarque pratique |
|---|---|---|
| Lister le contenu d’un tar.gz | tar -tzf fichier.tar.gz | Permet de vérifier la structure avant l’extraction. |
| Extraire un fichier tar | tar -xvf fichier.tar | Pas de compression, extraction simple. |
| Extraire un fichier tar.gz | tar -xvzf fichier.tar.gz | Option -z pour la compression gzip. |
| Extraire un fichier tar.bz2 | tar -xvjf fichier.tar.bz2 | Option -j pour la compression bzip2. |
| Configurer le logiciel | ./configure –prefix=/usr/local | Choix du préfixe d’installation. |
| Compiler | make | Peut être parallélisé avec make -j4, selon la machine. |
| Simuler l’installation | make -n install | Affiche les chemins sans écrire sur le disque. |
| Installer | sudo make install | Nécessite les droits administrateur. |
| Supprimer le dossier de build | rm -rf dossier | À faire uniquement après validation du fonctionnement. |
Installer un tar.gz n’est pas créer un paquet : penser maintenance et mise à jour
Empiler les sudo make install sur un serveur de prod finit souvent par poser problème au moment des mises à jour ou des audits de sécurité. Contrairement à un package DEB ou RPM, un binaire installé depuis un tar.gz ne se gère pas avec apt ou dnf. Il faut donc anticiper sa maintenance.
Dans beaucoup de contextes industriels, l’étape suivante après une installation manuelle réussie consiste à transformer ce travail en recette reproductible : script Ansible, paquet maison, image de conteneur. L’idée n’est pas de se priver de la souplesse du tar.gz, mais de ne pas laisser chaque serveur dériver avec sa propre version compilée à la main.
Pour certains projets tiers, la bonne stratégie consiste même à contourner l’installation système classique et à rester sur un déploiement dans un répertoire dédié (par exemple /opt/monlogiciel), géré par un superviseur ou un conteneur. On gagne alors en isolation au prix d’un peu de configuration supplémentaire du PATH et des services.
Quand préférer un DEB, un RPM ou un autre format
Installer un logiciel via fichier tar.gz n’est pas toujours la meilleure option, surtout quand un paquet officiel existe pour la distribution utilisée. Un DEB ou un RPM gère la désinstallation, les scripts de pré/post-installation et l’enregistrement dans la base de packages. À l’échelle d’un parc, cette traçabilité compte plus qu’on ne le croit.
Pour des environnements où l’on reçoit aussi des .rpm, un autre guide détaillé existe pour couvrir ce cas de figure : installer un fichier rpm sous Linux. L’idée générale reste la même : choisir la méthode la plus maintenable sur la durée, plutôt que la plus rapide le jour de l’installation initiale.
Au final, le tar.gz garde tout son intérêt pour tester rapidement une nouvelle version, déployer un outil interne ou intégrer un composant qui n’a pas d’emballage officiel. Pour tout le reste, le gestionnaire de paquets de la distribution garde une nette longueur d’avance côté maintenance.
Comment installer rapidement un fichier tar.gz sous Linux sans tout casser ?
La méthode la plus simple consiste à créer un répertoire dédié (par exemple /usr/local/src), y copier le fichier tar.gz, puis l’extraire avec tar -xvzf fichier.tar.gz. On entre ensuite dans le répertoire créé, on lit les fichiers README et INSTALL, puis on suit la séquence ./configure, make, make -n install, et enfin sudo make install si tout est cohérent. Cette approche évite de disperser les sources et permet de contrôler les chemins d’installation grâce aux options de ./configure.
Quelle différence entre un fichier .tar et un fichier .tar.gz ?
Un fichier .tar est une archive non compressée qui regroupe plusieurs fichiers et dossiers en un seul fichier. Un fichier .tar.gz est cette même archive tar, compressée avec gzip pour réduire sa taille. Sous Linux, on utilise tar -xvf pour extraire un .tar, et tar -xvzf pour extraire un .tar.gz, l’option -z indiquant la présence de la couche gzip.
Faut-il toujours utiliser sudo make install pour terminer l’installation ?
Non, et c’est même parfois déconseillé. sudo make install installe le logiciel au niveau du système, ce qui peut entrer en conflit avec des paquets existants. Pour un simple test, il est souvent plus sage d’installer dans un préfixe utilisateur (par exemple via ./configure –prefix=$HOME/.local) ou de se limiter à un usage dans un répertoire isolé. En production, mieux vaut encapsuler le tout dans un paquet ou un conteneur.
Comment connaître les dépendances nécessaires avant de compiler un tar.gz ?
La première source d’information reste les fichiers README, INSTALL ou parfois un dossier doc qui détaillent les bibliothèques requises, souvent avec leurs noms de paquets pour différentes distributions. On peut aussi lancer ./configure et lire attentivement les messages d’erreur en cas d’échec, qui pointent généralement les dépendances manquantes. Certains projets fournissent un script ou un fichier .spec qui liste l’ensemble des prérequis.
Peut-on désinstaller proprement un logiciel installé depuis un tar.gz ?
Ce n’est pas automatique comme avec un gestionnaire de paquets. Certains projets proposent une cible make uninstall qui supprime les fichiers installés, à condition que le Makefile l’implémente correctement. Si ce n’est pas le cas, il faut s’appuyer sur le résultat de make -n install ou sur la documentation pour retrouver et supprimer manuellement les fichiers. D’où l’intérêt de noter les options de ./configure et les chemins utilisés au moment de l’installation.
