Cela fait plus de 10 ans que je développe sous GNU/Linux en C++. Je faisais souvent des applications pour les serveurs qui étaient gérés par moi ou mon équipe. Faire des programmes portables Windows-GNU/Linux est donc quelque chose que je maitrise bien.
Par contre avec la sortie de Mtp Target sous GNU/Linux, je me suis lancé dans quelque chose de nouveau ; la distribution d’un logiciel sous GNU/Linux.
Sous Windows, j’ai l’habitude, un coup de NSIS pour faire l’installer et le tour est joué. Bon, ce n’est pas aussi simple, il faut gérer les problèmes sous VISTA, les problèmes de directX et beaucoup d’autres petits soucis, mais je gère.
La question était donc : comment faire pour que Mtp Target soit jouable par tous les Linuxiens.
La première piste était de faire comme sous Windows ; un installer. Il en existe un certain nombre qui marche plutôt pas mal. Le plus simple est makeself, c’est celui qui est utilisé par Id Software et nVidia. C’est en ligne de commande, on exécute, ça déarchive et exécute un script si nécessaire.
Sauf que voilà, le gros problème est que lorsque l’on télécharge un programme sous GNU/Linux, les droits d’origine ne sont pas gardés, donc on se retrouve avec un programme sans le bit d’exécution et quand on double clique dessus, ça l’ouvre dans un éditeur de texte ! Il faut que l’utilisateur s’y connaisse pour ajouter le bit d’exécution et ensuite l’exécuter. La raison invoquée est que c’est une question de sécurité. Un utilisateur pourrait télécharger un programme sans le faire exprès et l’exécuter.
La solution choisie par Mozilla est de créer une archive “.tar.bz2”. L’avantage est qu’il suffit de double cliquer sur l’archive pour que ça l’ouvre grâce au logiciel associé. Ensuite, l’utilisateur drag&drop le répertorie contenu dans l’archive où il le souhaite et il peut exécuter ce qui va bien. Je ne trouve pas que ça soit l’extase, mais au moins ça marche sans bidouiller, car les droits sont gardés dans l’archive.
Autre problème, impossible d’associer une icône à l’exécutable. Encore une fois, la raison invoquée est la sécurité (oui, sinon on pourrait mettre une icône d’un autre logiciel pour se faire passer pour celui çi). Mais bonne nouvelle, il est possible de créer une sorte de raccourci à la Windows, c’est un fichier texte qui contient le path vers l’exe, une icône, etc. Super ! Sauf qu’en fait non, c’est naze, on ne peut pas mettre de chemin relatif vers l’exe!!! Ca serait trop simple, on peut pas faire : path=bin/myexe, il faut un chemin absolu, sauf que bien sûr, comme l’utilisateur peut extraire le jeu n’importe où, il est impossible de créer ce fichier, donc retour à la case départ, pas d’icône.
Problème suivant ; mon jeu utilise une lib dynamique, FMod. Sous Windows, c’est simple, l’exe va automatiquement chercher les lib dynamiques dans un ordre précis, d’abord dans le répertoire courant, puis dans des répertoires spécifiques. Sous GNU/Linux? Il cherche dans les chemins définis dans la variable d’environnement LD_LIBRARY_PATH. Il est donc impossible de lancer le jeu directement, car il ne trouve pas la lib dynamique. Il faut donc écrire un script Shell qui va ajouter le chemin courant dans LD_LIBRARY_PATH puis exécuter le jeu. Sauf que c’est un script, et donc quand on double clique dessus, ça pop une message box demandant à l’utilisateur s’il veut l’exécuter, l’éditer, etc. Malgré le bit d’exécution !
Dernier souci ; la portabilité. Si je veux que le jeu marche sur un maximum de distribution GNU/Linux, il faut que je limite les dépendances avec les librairies externes. Chaque dépendance risque de poser un problème, car chaque distribution a sa propre version de chaque librairie. Il faut donc *tout* compiler en librairies statiques.
Dans les versions récentes de gcc, le compilateur ajoute un système de stack check pour limiter les bugs, sauf que, pas de bol, il faut la GLIBC 2.4 pour que cela fonctionne, sauf que ce n’est pas très répandu encore. Donc tous les utilisateurs qui tournent sur des distribs avec la GLIBC inférieure à 2.4 ne pourront lancer le jeu. Après une grosse prise de tête, j’ai enfin trouvé le moyen de retirer ce système et donc retirer les symboles dépendants de la GLIBC 2.4. Ouf…
Après tous ces problèmes, j’ai finalement réussi à faire un package unique qui fonctionne sur quasiment toutes les distribs GNU/Linux!
J’ai toujours le problème du script qui ne veut pas se lancer automatiquement quand on double clique dessus. Toujours pas d’icône associée au script. Pas de version 64bits (mais ça marche bien avec l’émulation automatique). Pas d’ajout du jeu dans le menu… La solution ultime serait peut-être un tar.bz2 qui contient un installer mais ça ne règlera pas tous les problèmes.
Quand je discute avec des fans de GNU/Linux, leur réponse est toujours la même, c’est naze ce que tu fais, la bonne façon de faire est de créer un package. Sauf que le système de package est différent sur chaque distrib! Ça veut dire que si je veux que mon jeu soit disponible partout, je dois créer une bonne 10ène de version du jeu ! C’est vrai que c’est mieux intégré, mais ça demande un boulot monstre. Prenons par exemple le simple cas de la distrib Debian, si je veux que tous les utilisateurs Debian puissent jouer à Mtp Target, il faudrait que je fasse un package debian, sauf qu’il y a plusieurs versions de Debian, etch, lenny, sarge, woody… Donc, il faudrait en théorie faire autant de package que de version de Debian, donc au moins 3 pour Debian. Je vous laisse imaginer le boulot (nombre de distrib * nombre de versions par distrib)!
Peut-être qu’un jour il y aura assez de monde dans la communauté de Mtp Target pour faire ce boulot, mais ce n’est pas quelque chose que je peux faire tout seul. Mon système n’est pas parfait, mais il permet au moins à tout le monde sous GNU/Linux de jouer à Mtp Target sans dépendre d’une distrib ou d’une version de distrib. Je n’ai à ce jour aucun linuxien qui est venu me voir en disant que ça ne marche pas chez lui.
