Souvent, il existe plusieurs programmes qui rendent le même service, et le
choix de l'un ou de l'autre est une question personnelle. Par exemple, pour
visionner un fichier texte, on peut choisir more
,
less
ou most
. Ils permettent tous de faire plus ou
moins la même chose, mais offrent une sensation différente. Quand on les
appelle directement, le problème ne se pose pas, on prend celui qu'on veut,
mais comment dire à la commande man
qu'on veut qu'elle utilise tel
ou tel pageur ?
Si on veut résoudre le problème proprement, il faut aussi s'intéresser aux
alternatives esclaves d'autres. Si on a choisi vi
comme éditeur,
il faudrait qu'on puisse voir la page de manuel de vi
avec quelque
chose comme man éditeur.
Petit digression de Charles Goyard <charles.goyard@laposte.net> qui n'a pas grand chose à faire là, mais qui me fait rire : sous Windows, lorsque Netscape est lancé, et que je tape la commande « ftp », c'est Netscape qui récupère l'adresse et qui ouvre la session FTP, ce qui est particulièrement pénible pour les serveurs non anonymes. Il existe donc un mécanisme similaire sous Windows, mais il est incontrôlable à moins d'être certifié Microsoft. On est content.
Les programmes qui suivent les recommandations de GNU utilisent des variables
d'environnement pour ce genre de réglage. Par exemple, si l'utilisateur fixe
la variable EDITOR à vim, c'est la commande vim
qui
sera invoquée chaque fois qu'un programme GNU aura besoin de faire éditer un
texte (la commande crontab -e utilise ce mécanisme).
La principale limite de cette approche est qu'elle demande de modifier tous les programmes clients pour qu'ils recherchent la bonne variable d'environnement. De plus, sauf erreur de ma part, ce mécanisme n'a été mis en place que pour quelques fonctionnalités : PAGER, qui choisi le pageur et EDITOR, qui choisit l'éditeur. Si vous connaissez d'autres alternatives par variable d'environnement, n'hésitez pas à m'en faire part, je les mettrai ici. Mais quoi qu'il en soit, on est loin du nombre d'alternatives à la Debian, puisque sur mon système, je n'en ai pas moins de 200...
De plus, je ne vois pas comment utiliser cette ruse pour gérer les alternatives esclaves.
La solution Debian passe par les alternatives, qui habitent dans le répertoire
/etc/alternatives, et une belle collection de liens. Par exemple,
comme j'aime mieux le pageur less
, j'ai les liens suivants sur ma
machine :
/usr/bin/pager -> /etc/alternatives/pager -> /usr/bin/less
Comme ça, man
n'a plus qu'à appeler la commande
pager
, et le programme less
est automatiquement
appelé.
Cette réponse engendre une nouvelle question : pourquoi trois liens ? La situation suivante permettrait de faire la même chose :
/usr/bin/pager -> /usr/bin/less
Oui, ça aurait le même effet, mais ça serait plus compliqué à administrer.
Centraliser les alternatives dans un seul répertoire permet de rendre cohérent
le système. Ainsi, il est beaucoup plus simple de savoir ce que le système des
alternatives propose, par un simple ls /etc/alternatives/, au lieu
de fouiller sur tout le disque dur. De plus, si on travaille en réseau, cela
rend possible de partager les binaires entre les machines par un montage nfs de
/usr tout en permettant à chaque machine d'avoir des réglages
spécifiques. Enfin, cela permet d'écrire un script gérant tout ça
automatiquement. Et même, ce script existe déjà, il s'appelle
update-alternatives
, il vient avec le paquet dpkg
(et
est donc déjà sur votre machine), et il n'est accessible qu'à root.
Ce programme est utile à la fois pour les paquets, qui l'utilisent pour
s'enregistrer comme fournisseurs de fonctionnalités, et pour l'administrateur,
qui l'utilise pour dire quels sont les programmes par défaut. Je ne m'attarde
pas ici sur la première partie, car, c'est bien connu, ceux qui font des
paquets Debian sont des surhommes capables de tout, même de lire la page du
manuel update-alternatives(8)
correspondante... (ceux qui ne sont
pas des surhommes capables de tels prodiges, mais qui sont curieux quand même
peuvent se référer à la partie Ajouter ou enrichir une
alternative proprement, Section 7.7)
Pour l'administrateur, il faut savoir que chaque possibilité de l'alternative a une priorité donnée par le mainteneur du programme, et que donc, on peut très bien laisser le système se débrouiller seul la plupart du temps.
Notons aussi au passage que le programme gère les liens esclaves de manière transparente, dans les versions non boguées (voir plus loin).
Bien, reste à voir comment utiliser ce beau programme. Le plus simple, c'est encore un bon vieux update-alternatives --help qui donne les différentes façons de l'utiliser. Les seules qui intéressent l'administrateur (et non les mainteneurs) sont :
Essayez l'option --config, c'est beau à voir. L'architecture est en place pour un bel outil cliquable pour ceux qui veulent, reste plus qu'à le faire...
Dernier point important auquel il me faut répondre : où trouver la liste des alternatives gérées par le système ? Il suffit de faire un ls /etc/alternatives. Bon, c'est vrai, ça ne montre que les alternatives actuellement installées sur votre machine, mais bon, cela devrait suffire à la plupart d'entre nous.
Les vieilles versions de dpkg
(ie, les versions antérieures à la
1.7.1 du 7 Novembre 2000, ce qui inclut celle de potato :) avaient pas mal de
problèmes avec update-alternatives
. Par exemple, quand on mettait
a jour une alternative, elle n'était pas mise dans le mode "manuel",
et donc, a la mise à jour suivante, tout était à refaire. De plus, les liens
esclaves n'étaient pas non plus mis à jour. Tout ceci gâche un peu l'intérêt
du système, je vous l'accorde. Mais bon. Cela n'en est pas moins la bonne
méthode de résoudre le problème sous Debian. Pour consoler les utilisateurs de
potato, disons que c'est la méthode d'avenir...
C'est que la méthode Debian est bien gentille, mais elle ne permet que de faire des réglages par défaut sur une machine, et non sur un compte.
Il n'y a malheureusement pas encore de méthode Debian de le faire, mais on peut quand même s'en sortir facilement :
export PATH=$HOME/bin:$PATH export MANPATH=$HOME/man:$MANPATH
Ensuite, il suffit de mettre des liens dans les répertoires bin et man
correspondants, tout comme update-alternatives
le fait dans
/etc/alternatives. On peut même rêver que ce programme sera un
jour accessible au commun des mortels (et pas seulement root), et qu'il fera
quelque chose du genre...
Pour ajouter une alternative dans le cas d'un logiciel installé à la main dans /usr/local, ou dans le cas d'un paquets .deb qui n'utilise pas les alternatives comme KDE :
update-alternatives --install /usr/bin/x-window-manager\ x-window-manager /usr/bin/kde 500\ --slave /usr/share/man/man1/x-window-manager.1.gz x-window-manager.1.gz\ /usr/share/man/man1/kde.1.gz
500 est la priorité dans la liste des alternatives (on peut mettre ce qu'on veut, le choix par défaut est celui ayant la priorité de valeur la plus grande).
La FAQ de la liste debian-user-french@lists.debian.org
15 avril 2002debian-user-french@lists.debian.org
mquinson@ens-lyon.fr
thierry.laronde@polynum.com
C.Martin@ipnl.in2p3.fr
Frederic.Petit@univ-mlv.fr