Entre les paquets installés par défaut, ceux ajoutés ensuite et ceux que vous installez à la main selon vos nécessités, il devient parfois difficile de connaître la version d’une commande appelée. Plus le composant en question est populaire, plus les chances d’en trouver plusieurs versions dans votre environnement sont grandes.
Dans cet article, nous allons voir comment utiliser la commande « alternatives » pour Java. C’est un exemple populaire car il est fréquent de voir plusieurs applications installer chacune leur version. Le cas peut se présenter également pour Python (avec des contraintes entre Python2 et Python3) ou MySQL (dont le client est souvent une dépendance pour des paquets d’outils).
Sur la machine de test, la commande « alternatives –list » affiche ceci (résumé) :
java auto /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-5.b16.fc24.x86_64/jre/bin/java jre_1.8.0 auto /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-5.b16.fc24.x86_64/jre java_sdk_1.8.0_openjdk auto /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-5.b16.fc24.x86_64
C’est propre. Trop propre.
Téléchargeons une version récente (8u111 à l’heure où ces lignes sont rédigées) depuis le site officiel. Nous allons l’installer dans un répertoire différent :
mkdir ~/tmp/opt cp jdk-8u111-linux-x64.tar.gz ~/tmp/opt && cd ~/tmp/opt tar -xvzf jdk-8u111-linux-x64.tar.gz
Aparté : « tar -xvzf » est une mauvaise habitude. Le « v » demande l’affichage des noms de fichiers en train de s’extraire. C’est inutile et, parfois, prend dix fois plus de temps que l’extraction elle-même.
Scène de rupture après utilisation de Tar en mode verbeux (Chine, XIeme siècle, collection privée)
SHELL> time tar -xvzf archiveAvecCentaineDeFichiers.tar.gz real 0m6.448s user 0m1.802s sys 0m3.554s SHELL> time tar -xzf archiveAvecCentaineDeFichiers.tar.gz real 0m5.572s user 0m1.775s sys 0m2.293s
Une seconde de différence sur une petite archive. Cela peut peser bien plus lourd si vous faites l’extraction depuis une machine distante : 2 secondes d’écart, soit 50% de plus !
Fin de l’aparté.
Revenons-en à nos alternatives. Pour ajouter notre nouvelle version au catalogue du système (une Fedora 24), la commande est de la forme » alternatives –install <lien_qui_doit_etre_crée> <nom> <vrai_chemin_du_nouveau_binaire> [<priorité>] » :
sudo alternatives --verbose --install /usr/lib/java java ~/tmp/opt 2000
« 2000 » est un chiffre arbitraire indiquant la priorité des alternatives entre elles. Ça ordonne la liste du menu.
Mais quel menu ? Cela montré par la commande « alternatives –config java » :
Il existe 2 programmes qui fournissent « java ». Sélection Commande ----------------------------------------------- *+ 1 /opt/java/ 2 /opt/jdk1.8.0_121/ Entrez pour garder la sélection courante [+] ou saisissez le numéro de type de sélection :
Note : l’exemple est tiré d’une autre machine. Nous y reviendrons.
Ainsi, grâce à l’option « –config », vous pouvez configurer la version du logiciel au niveau du système. Très pratique en cas de montée de version.
Ou bien (comme c’était le cas pour nous), pour être certain que tous les utilisateurs utilisent bien la dernière version installée. Autre avantage : pas besoin de modifier tous les fichiers de configuration des shells utilisateurs en cas de changement.
Naturellement, cela peut toujours être surchargé par lesdits utilisateurs avec un « EXPORT JAVA_HOME=… » manuel.
Avant de conclure, revenons sur l’exemple pour lequel nous avons dû utiliser le résultat d’une autre machine. En effet, sur celle choisie pour tester, la commande échouait avec l’erreur :
le lien primaire pour java8 doit être /usr/lib/java
Cela provient d’une installation incorrecte sur cette machine : l’administrateur à sans doute extrait puis copié une archive de la JRE directement dans /usr/bin/. Par conséquent, le système ne peut pas créer de lien symbolique du même nom. Il a fallu corriger manuellement en déplacement le répertoire fautif.