Copyright © 2003 David Lechnyr
Lorsqu'ils installent des logiciels, de nombreux utilisateurs sont désorientés : doivent-ils le faire dans /usr/sbin, /usr/local, /usr/local/nom_paquetage ? Croire de surcroît en « une seule manière correcte » d'installer des logiciels ajoute à cette confusion. Dans ce court article, nous espérons qu'un certain nombre d'entre elles sera éliminé, de façon à ce que l'utilisateur puisse effectuer un choix éclairé.
Le Filesystem Hierarchy Standard (FHS, standard de hiérarchie du système de fichiers) est une référence sur la manière de gérer un système de fichiers ou une hiérarchie de répertoires Unix. Malheureusement, le public suppose qu'il s'agit d'un standard et/ou d'un tutoriel, ce qui est le contraire de son rapport de mission. Le FHS est un sous-ensemble de la Linux Standard Base (LSB, base de standards Linux), qui défend un ensemble de standards visant à augmenter la compatibilité entre les distributions Linux et à permettre aux applications logicielles de s'exécuter sur tout système s'y conformant. Cependant, intentionnellement ou non, ces standards ont tendance à être adoptés par les vendeurs de distributions Linux plutôt que par les mainteneurs de paquetages logiciels.
Prenons par exemple, Samba. Le répertoire d'installation par défaut de Samba est /usr/local/samba. Nombre d'utilisateurs se plaignent que ce type de comportement viole le FHS. Ce qu'ils n'arrivent pas à réaliser est ce que nous avons énoncé précédemment : l'adoption du FHS semble être encouragée par les vendeurs de distributions Linux plutôt que par les mainteneurs de logiciels Linux. Il est assez difficile de savoir pourquoi il en est ainsi et si cela est intentionnel ou non. Malgré tout, l'effet produit n'est pas sans rappeler « un chien qui aboie après sa propre queue » - le public se plaint d'un aspect alors qu'il n'a jamais été le centre de l'attention au premier chef. Que cela soit intentionnel ou non est au mieux une question discutable ; c'est ainsi que les choses se déroulent actuellement.
L'emplacement d'installation d'un grand nombre de paquetages est traditionnellement imprégnée d'une priorité historique. Beaucoup de mainteneurs de logiciels affirment qu'ils installent dans /usr/local/nom_paquetage non par méthode ou philosophie, mais plutôt parce qu'ils ont toujours procédé ainsi. Et dans l'univers bien huilé du logiciel, « si ce n'est pas cassé, on ne répare pas ».
Non que je désapprouve. La priorité historique est un point important. En revanche, le FHS a d'excellentes idées vis-à-vis de la standardisation de l'emplacement des fichiers et des répertoires installés. Cependant, ce n'est rien de plus qu'une philosophie, rien n'incite à s'y conformer. En ne la privilégiant pas, en encourageant leur philosophie à l'égard ni des mainteneurs de paquetages ni des vendeurs de distributions Linux, la réaction de la communauté Internet au FHS semble, si l'on y réfléchit, venir du vendeur de distributions. Ceci constitue véritablement une partie du problème.
L'attention portée à la conformité au FHS, intentionnellement ou non, devrait être placée sur les développeurs de logiciels. Certains des problèmes plus traditionnels s'en trouveraient clarifiés. Par exemple :
Exemple 1. Avant l'avènement du FHS
Un utilisateur installe Red Hat Linux. Quelque temps après, il décide de mettre à jour un des paquetages logiciels à la main. Aucun conflit d'emplacement de fichiers n'apparaît, puisque l'emplacement d'installation sous Red Hat Linux de chaque programme est déterminé par le vendeur. Les paquetages installés dans /usr/local/nom_paquetage seront remplacés par des fichiers au même endroit.
Exemple 2. Après l'avènement du FHS
Un utilisateur installe Red Hat Linux. Quelque temps après, il décide de mettre à jour un des paquetages logiciels à la main. Toutefois, ce dernier est installé dans /usr/bin et /usr/sbin, ainsi que quelques fichiers de données variables dans /var/lib/nom_paquetage. Le paquetage actualisé qu'il vient de télécharger installe tout par défaut dans /usr/local/nom_paquetage. Étant un utilisateur Linux moyen, il est un peu perplexe devant les conflits que cette opération risque d'introduire dans son système et a des doutes sur la manière de procéder.
Je pense personnellement que nous considérons la conformité au FHS sous le mauvais angle. Une autre réalité future, qui serait probablement bien meilleure, serait :
Exemple 3. Dans le futur
Un utilisateur installe Red Hat Linux. Quelque temps après, il décide de mettre à jour un des paquetages à la main. Aucun conflit d'emplacement de fichiers n'apparaît, puisque l'emplacement d'installation sous Red Hat Linux de chaque logiciel est déterminé par le vendeur de logiciels se conformant au FHS (et non par Red Hat). Red Hat lui-même n'apporte aucune modification aux emplacements par défaut de chaque paquetage. Les paquetages installés sur le système par RPM ou compilés à la main remplaceront les fichiers sur le système au même endroit exactement.
Avec l'arrivée de la version 2.3 du FHS, il devient bien plus important que nous nous intéressions aux vrais problèmes. Pour réussir à réduire la confusion dans le monde des logiciels installables sous Linux, nous devons non seulement nous concentrer sur notre philosophie et notre méthode, mais aussi nous adresser au bon public. Nous espérons que cet article vous a aidé à mieux prendre conscience des problèmes existants.
Quelques-unes parmi les nombreuses distributions qui essaient de maintenir une conformité au FHS incluent :
David Lechnyr est administrateur réseau pour le département Ressources Humaines de l'université de l'Oregon. Il est titulaire d'une maîtrise de sociologie, ainsi que des certifications MCSE+I, CNE et CCNA. Il travaille avec Linux depuis plus de sept ans, plus particulièrement sur la sécurité des systèmes, la maintenance des réseaux et l'intégration PHP/MySQL. Il est également l'auteur du Unofficial Samba HOWTO et du Linux+Apache+MySQL+PHP HOWTO.
Copyright © 2003, David Lechnyr.
Copying license http://www.linuxgazette.com/copying.html
Paru dans le n°93 de la Linux Gazette d'août 2003.
Traduction française par Isabelle Hurbain <isabelle POINT hurbain CHEZ free POINT fr>.
Relecture de la traduction française par Joëlle Cornavin <jcornavi CHEZ club-internet POINT fr>.