Fichier tar.gz sous Linux : comment l’installer sans lancer des commandes au hasard

Un fichier .tar.gz sous Linux n’est pas forcément un programme à installer. C’est d’abord une archive compressée. Elle peut contenir un binaire prêt à lancer, un script d’installation, du code source à compiler, ou simplement des fichiers à copier.

Le piège, c’est de télécharger l’archive, de l’extraire, puis de lancer le premier install.sh trouvé avec sudo. Mauvaise idée. Avant d’exécuter quoi que ce soit, il faut regarder ce que contient l’archive et comprendre le mode d’installation prévu.

Commencez par identifier le fichier

Placez l’archive dans un dossier de travail, pas directement dans /usr/local ou dans un répertoire système. Par exemple :

mkdir -p ~/tmp/installation-test
cp logiciel.tar.gz ~/tmp/installation-test/
cd ~/tmp/installation-test

Vérifiez ensuite le type réel du fichier :

file logiciel.tar.gz
ls -lh logiciel.tar.gz

Si l’archive est très volumineuse, vérifiez aussi l’espace disque disponible avant extraction. Sur un petit VPS ou une partition /home limitée, ça évite une extraction qui s’arrête au milieu. Le guide sur les commandes d’espace disque sous Linux peut vous servir dans ce cas.

Lister le contenu avant d’extraire

Avant d’extraire, listez le contenu de l’archive. C’est la commande que je lance presque toujours en premier :

tar -tzf logiciel.tar.gz | head -50

Vous devez repérer si l’archive contient un dossier racine propre, par exemple logiciel-1.2.3/, ou si elle déverse directement des fichiers dans le dossier courant. Dans le doute, extrayez toujours dans un dossier vide.

mkdir extraction
tar -xzf logiciel.tar.gz -C extraction
cd extraction

La commande tar est documentée dans la page de manuel tar(1). Pour un .tar.gz, les options courantes sont -x pour extraire, -z pour gzip et -f pour indiquer le fichier.

Cherchez les instructions fournies par le projet

Une fois l’archive extraite, cherchez les fichiers d’instructions :

find . -maxdepth 2 -iname 'README*' -o -iname 'INSTALL*' -o -iname 'CHANGELOG*'

Lisez-les avant de lancer un script. Oui, c’est moins rapide que copier une commande trouvée sur un forum. Mais c’est là que vous verrez si le projet recommande un paquet .deb, un dépôt officiel, un binaire portable, ou une compilation.

less README.md
less INSTALL

Si le logiciel existe dans les dépôts de votre distribution, privilégiez souvent le gestionnaire de paquets. Il gère les mises à jour, les dépendances et la désinstallation proprement.

apt search nom-du-logiciel
dnf search nom-du-logiciel
pacman -Ss nom-du-logiciel

Cas 1 : l’archive contient un binaire prêt à lancer

Certains projets livrent directement un exécutable. Vous pouvez le repérer avec file et ls -l :

find . -maxdepth 3 -type f -perm -111 -print
file ./nom-du-programme

Avant de l’installer globalement, testez-le depuis le dossier extrait :

./nom-du-programme --version
./nom-du-programme --help

Si le binaire fonctionne et que la documentation le permet, vous pouvez le placer dans /usr/local/bin. Renommez-le clairement et gardez une trace de ce que vous avez copié.

sudo install -m 755 nom-du-programme /usr/local/bin/nom-du-programme
command -v nom-du-programme
nom-du-programme --version

Cas 2 : l’archive contient un script install.sh

Un script install.sh peut être parfaitement légitime. Mais il peut aussi modifier des fichiers système, créer des services, ajouter des dépôts ou télécharger d’autres composants. Regardez-le avant de l’exécuter.

less install.sh
grep -nE 'sudo|curl|wget|systemctl|/usr|/etc|rm -rf' install.sh

Si vous ne comprenez pas ce que fait le script, ne le lancez pas avec sudo. Testez d’abord la documentation, cherchez une option --help, ou utilisez une machine de test.

sh install.sh --help

Sur un serveur, je préfère toujours savoir précisément quels fichiers seront créés. Si le script installe un service systemd, vérifiez ensuite le service avec systemctl daemon-reload seulement si un fichier d’unité a été ajouté ou modifié.

Cas 3 : il faut compiler le programme

Si vous voyez des fichiers comme configure, Makefile, CMakeLists.txt ou meson.build, vous êtes probablement face à du code source. La séquence classique ressemble à ceci :

./configure
make
sudo make install

Mais ne copiez pas cette suite sans réfléchir. Les dépendances, le préfixe d’installation et la commande de désinstallation varient selon les projets. Quand c’est possible, installez dans /usr/local ou dans votre dossier utilisateur, pas au hasard dans le système.

./configure --prefix=/usr/local
make -j"$(nproc)"

Avant sudo make install, regardez si une cible de désinstallation existe :

make -n install
make -n uninstall

make -n affiche les commandes prévues sans les exécuter. Ce n’est pas une garantie absolue, mais c’est une bonne vérification avant de modifier une machine propre.

Vérifier que l’installation fonctionne

Après installation, vérifiez d’où vient la commande et quelle version répond :

command -v nom-du-programme
nom-du-programme --version

Si un service a été installé, contrôlez son état et ses logs :

systemctl status nom-du-service --no-pager
journalctl -u nom-du-service -n 80 --no-pager

Pour un outil installé à la main, notez aussi son emplacement et la méthode utilisée. Le jour où vous devrez le mettre à jour ou le supprimer, cette petite trace vous évitera de chercher dans tout le système.

En résumé pratique : un .tar.gz s’inspecte avant de s’exécuter. Listez le contenu, extrayez dans un dossier propre, lisez le README, puis choisissez la méthode adaptée. Si vous devez utiliser sudo, vous devez savoir exactement pourquoi.