Quand on bugfix à moitié, quand on release sans tester

Je dois installer GTK+ 2 et d’autres logiciels pour diverses raisons, et dont je dois compiler moi-même le code source, pour diverses raisons encore. Je télécharge la dernière version à ce jour, là 2.24.5: gtk+-2.24.5.tar.bz2 du 15-Jun-2011 19:23 (http://ftp.gtk.org/pub/gtk/2.24/)… et je me retrouve confronter à un bug remonté et corrigé datant d’avril 2011, voir ici. Malgré la correction, la dernière release ne contient pas le correctif. On peut voir sur la page du bugzilla, qu’une personne (Colin Walters), qui est développeur apparemment, a validé le correctif de Kalev Lember. Ce même développeur a « pushé » le correctif selon ses dires, et je le crois.

Le hic est que le bug a été rapporté pour la version 3.0 de GTK+, et non la version 2.0. Du coup le correctif, on l’aura jamais sauf si un autre rapport de bug est crée. Or GTK 3.0 est récent et la branche 2.0 est toujours supporté. Ce qui signifie simplement que le gars n’a pas cherché plus loin que le bout de son nez. « Ca bug dans la v3 ? Ok je corrige que la v3, osef de vérifier si le bug est aussi dans la v2, et puis ça forcera les gens à passer à la v3« .

Voici un autre problème que j’ai eu, la compilation d’un logiciel (libsigc++-2.2.3) qui foire parce qu’il est impossible de générer la documentation. Ah pire, il y a même une segmentation fault dans la génération de la documentation. C’est xsltproc qui est utilisé à cette finalité et qui plante, un soft Gnome. Juste avant le segfault, j’ai un message qui m’indique qu’une variable d’environnement est non définie. Mais cela ne semble pas être lié, ce serait quand même fort un segfault à cause d’une variable non définie.

Bien sûr, –disable-docs ne fonctionne pas alors que ce serait énormément utile pour ce programme avec beaucoup de documentation. La solution pour ne plus avoir le segfault a été de remplacer xsltproc par le programme /bin/true (par un lien symbolique) pour faire croire que la génération fonctionnait correctement. Cependant, cela n’a pas tout résolu, un autre problème venait de la copie de fichiers lors de l’installation. En effet, l’installeur essayait de copier un dossier inexistant, le dossier tutorial qui a du être supprimé avec le temps et qui du coup faisait planter l’installation. Le font-ils exprès ?

La grande question est es-ce qu’ils ont au moins testé une fois que leur logiciel (leur merde ?) s’installait correctement ? J’espère que oui et ça a du marcher surement grâce à des versions du programme d’installation différent (/usr/bin/install ?) ou d’environnement plus tolérant. Je ne vois pas d’autres solutions.

Ensuite, il y a les programmes qui se foutent des standards, comme pour le .config vu dans un article précédent. La sauvegarde des fichiers package config s’effectue dans /lib/pkgconfig, il y en a qui ont décidé de faire chier et d’aller se mettre dans /share/pkgconfig. C’est la vrai jungle linux… codé par qui/quoi déjà ?

Après il y a aussi les messages d’erreurs incomplets. Visuellement:

checking for XOpenDisplay… no
configure: error: *** libX11 not found. Check ‘config.log’ for more details.

et après il faut décortiquer config.log. Certes ce n’est pas compliqué, mais pourquoi ne pas donner simplement la solution plutôt que de dire grossièrement: "va voir l’erreur et débrouille toi pour y remédier".

GNU est une grosse déception aussi. J’ai eu à compiler binutils2.21.1, nickel la première fois. Quelques heures après je me décide à recompiler pour ajouter une option, mais entre temps j’avais changé la variable d’environnement LIBS. Pas de problème, il me chie dessus mais il me dit quoi faire, un make distclean. Sauf que, ça ne marche pas, malgré tous les cleans possible, il ne veut rien entendre, LIBS a changé et même en remettant la valeur d’origine cela ne marche pas. La solution ? Supprimer le dossier et décompresser à nouveau binutils… ou bien supprimer tous les config.status des sous-dossiers. Si les développeurs de GNU ne savent même pas faire un clean propre, où va t-on ? Ah linux. A croire que c’est fait exprès pour permettre à des entreprises de vendre du support… le seul modèle économique viable pour l’open source c’est bien vendre du support.

Avec GNU toujours, autant pour tous les autres logiciels la commande ./configure indique quels sont les paquets manquants qui vont faire obligatoirement échouer la compilation, autant pour binutils ce n’est pas bloquant. D’un certain coté c’est bien si jamais ./configure se trompe. Linux, la diversité des compilations, des installations et des bugs, le prix de la trop grande liberté ?

Pour finir, je vais rappeler l’exemple déjà énoncé dans un autre article, bumblebee. Le script d’installation qui possédait un bug, un espace supplémentaire a été inséré dans une commande de suppression qui provoquait la suppression complète du dossier /usr au lieu d’un simple fichier.

C’est ce qui arrive quand il n’y a aucune conséquence pécuniaire quand on fait une connerie: on ne fait pas attention, on fait ce que l’on veut pour le plaisir de le faire, pour le plaisir de faire plaisir aux autres et si ça rate tant pis, au pire on déçoit quelqu’un, alors pourquoi faire un travail de qualité professionnelle quand on s’investit dans le libre sur son temps libre ?

Cela me permet de faire naturellement le lien avec le système de dépôts/paquets de linux. Le système de dépôts, même si je l’ai beaucoup critiqué, est dans un sens pratique: il met à jour tous les logiciels facilement. Des systèmes équivalents ont vu le jour sur Windows (en plus de Windows Update), il y a ninite par exemple. C’est en effet pratique même si l’on devient dépendant d’une entité qui offre un service. Cependant, lors de mise à jour majeur d’une logiciel, ce sont des habitudes ou des fonctionnalités qui peuvent être perdu.

Mais dans le cadre de linux, les dépôts sont obligatoires pour les raisons évoquées ci-dessus: il est impossible d’installer soi-même un logiciel. Les paquets permettent de s’affranchir de toute la merde des développeurs en amont pour avoir un logiciel qui s’installe et marche. Les paquets nécessitent l’intervention d’une personne qui va compiler, configurer les fonctionnalités avec les options de configuration et pré configurer le logiciel pour vous, et en sous entendu: traiter tous problèmes éventuels pour faire réussir la compilation et le logiciel (car cela peut compiler, mais le logiciel peut ne pas marcher). Il faut cet intermédiaire obligatoire sur linux quand on n’est pas un bidouilleur (et là attention, tout fanatique vous répondra pour vous rassurer qu’il y aura toujours au moins un bidouilleur pour vous créer un paquet).

Etre dépendant à ce point, cela ne me plait pas du tout. Autant pour Windows, ce que fait ninite est grosso modo une automatisation d’installation, autant pour Linux, les paquets sont une valeur ajouté indispensable. Autant être dépendant des paquets (ou Windows Update) pour la mise à jour du système d’exploitation est une chose, autant pour des logiciels classiques c’est autre chose.

Certains diront que c’est un avantage, d’autres un inconvénient, car avec ce système de dépôts, une librairie peut-être mise à jour facilement. Par exemple zlib se met à jour (sans changer l’API existante quand même, donc une mise à jour de sécurité) et tous les programmes peuvent en profiter. Sous Windows, jamais on va se dire « tiens, je vais voir si il y a une nouvelle version de zlib », d’ailleurs on ne se le dit pas non plus sur linux, puisque ce sont les mainteneurs qui s’en occupent. Sous windows, la librairie zlib n’est pas forcément partagée, elle est incluse à chaque fois par l’assistant d’installation des programmes qui s’en servent. Anisi quand on installe un programme, il va installer tout ce qui est nécessaire à son fonctionnement, sauf cas particulier, genre les applications .NET qui ont besoin du framework .NET, ou bien de grosse application dont l’installateur principal va exécuter l’installeur d’un sous programme.

Sous linux, ce ne sont pas des cas particuliers, c’est le fonctionnement normal. Il y a une arborescence de dépendances entre les logiciels et les librairies, donc par exemple pour installer GTK+2.0, il faudra avant plein de paquets mais c’est un mauvais exemple car on peut considérer que GTK+2.0 c’est le coeur d’un système et personne n’aura à l’installer (à part les mainteneurs). Pour installer mumble, comme a pu le voir dans mon article sur les dépôts, il fallait installer plein de dépendances, la liste de paquets que l’on avait vu était les dépendances et les dépendances des dépendances. Du coup, qui détermine cette arborescence de dépendance ? la distribution, les mainteneurs. Ce n’est pas le développeur, lui il dit simplement qu’il faut telle librairie avec telle version pour compiler son programme. Il ne peut même pas aider les mainteneurs car le nom des paquets peut être différent entre les distribution. La création des paquets est un travail superflu qu’aucun développeur ne veut faire.

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :