petit defaut de jeux par rapprt à linux

[alexises]

jje tien à remarquer quelque petit defaut qui somme doute non aps d'importence mais qui pour un linuxien pur et dur si.
le fichier el.x86.linux.bin devrais étre séparer des sources et étres mis dans /usr/bin tendis ques le reste dans /usr/share/game/
le fichier el.ini devrais s'appeler le.conf pour respecter la nomenclature des fichier de configuration sous linux.
le dossier tmp devrais ne pas exister et le jeux devrais utiliser le dossier var de linux pour stocker ces resources temporaire.
les sources du jeux doivent contenir les donnée du jeux pour éviter à un empackteur de devoir repackager le jeux et la makefile contenir une sources make install pour pouvoir étre installer facilement

ces details sont peut étre inutile pour le moment mais si un projhet de paquet convenable est entrepris il faudra obligatoirement corriger ces problaimes.

[Teylae]

Tout a des avantages et des inconvénients !

La solution retenue permet de regrouper l'ensemble des fichiers à un seul endroit. J'ai un problème Landes Eternelles ? je sais où sont les fichiers, je n'ai pas besoin de chercher dans tous les recoins de Linux.
Ta solution est certes beaucoup plus dans l'esprit Linux, mais a l'inconvénient d'en mettre partout.

Cependant, ce que je te propose, à toi "Linuxien pur et dur", c'est l'utilisation de Mozilla Firefox comme navigateur. Celui-ci intègre nativement un correcteur orthographique fort agréable et facile d'utilisation. Il te permet d'être compris plus facilement par tes correspondants et de réaliser des messages beaucoup plus crédibles.

Sur ce, bon jeu ...

---> []

[norton]

l'essentiel n'est-il pas que le cela fonctionne sous ces 2 systèmes ?
Je joue d'ailleurs sur ces 2 versions et tout ça c'est bonnet blanc et blanc bonnet... je me fais autant massacrer..

[Wrandrall]

Hin hin hin qui disait que Linux était mieux que Windows?

[chaosmaster]

vive windows

[Agop]

Pour Wrandrall et ChaosMaster, la question n'était pas de comparer les deux systèmes d'exploitation, mais portait juste sur les normes à employer lorsque l'on veut créer un paquet Linux.
Windows aussi possède des normes abérrantes et est bourré de défauts donc sur ce point inutile d'insister je pense.
Quant au correcteur d'orthographe de Firefox il est pas hyper fiable non plus.
Sinon pour en revenir au sujet de départ il est vrai que si les corrections à apporter ne sont pas trop contraignantes, pourquoi ne pas les faire et obtenir de magnifiques paquets dans les règles de l'art.

[alexises]

j'ai aps pris le temps d'installer le paquet myspeel fr.
sinon pour le paquet si ces norme été respecter il serer beaucoup plus facile de mintenir un paquet : on édite le chenge log les no de version les source et on recompille et sa roule.

[TonyFlow]

Concernant les remarques sur la forme, afin de s'adapter au mieux à un environnement Linux, j'y ai été confronté en effet puisque je me suis lancé dans la réalisation d'un paquet RPM (pour Fedora). Au passage voir ce post pour les interessés : http://www.landes-eternelles.com/module ... 936&npds=1

le fichier el.x86.linux.bin devrais étre séparer des sources et étres mis dans /usr/bin tendis ques le reste dans /usr/share/game/

J'ai choisi de tout placer sous /usr/games/LandesEternelles/ (ayant choisi d'ailleurs "LandesEternelles" pour le nom de mon paquet).
Ensuite, certes l'exécutable s'y trouve, mais j'ai d'autres jeux installés en rpm sous /usr/games qui sont pareil (genre nethack et vultures, au moins ça regroupe les RPG !).
Après j'ai rusé un peu en ajoutant un petit script shell qui me sert de lanceur, il est placé dans /usr/bin/ avec un fichier .desktop sous /usr/share/applications qui l'appelle.
Donc finalement je m'en arrange très bien. D'ailleurs ce petit lanceur m'est très utile, car au lieu de lancer directement la commande /usr/games/LandesEternelles/el.x86.linux.bin, je me place d'abord dans le dossier avec un cd puis j'exécute ./el.x86.linux.bin. Et ceci est très important pour que le fichier el.ini soit créé la première fois dans le home de l'utilisateur depuis le modèle qui se trouve dans le dossier du jeu, car il est recherché dans le dossier courant...

le fichier el.ini devrais s'appeler le.conf pour respecter la nomenclature des fichier de configuration sous linux.

Ca me choque pas du tout. Chaque utilisateur a le sien dans le répertoire .lec de son home, c'est un bon emplacement et c'est le principal... Il n'y a pas vraiment d'extension de défini sous linux puisque ce concept n'existe pas à l'origine, il n'y a que windows pour déterminer le type d'un fichier selon son nom
C'est bien que le projet puisse coller à l'organisation linuxienne, mais faut pas oublier non plus qu'il doit être multiplateforme... Donc si ça ne nous gène pas, laissons le .ini

le dossier tmp devrais ne pas exister et le jeux devrais utiliser le dossier var de linux pour stocker ces resources temporaire.

Voui si on y tient pourquoi pas... Dans ce cas je pense que le plus simple serait que le dossier temporaire à utiliser soit spécifié dans le fichier de config el.ini car là je suppose que c'est en dur dans le code. Après le packageur pourra adapter le fichier de conf par défaut selon ses besoins...

les sources du jeux doivent contenir les donnée du jeux pour éviter à un empackteur de devoir repackager le jeux

Bon de toute manière le packageur, il a forcément du boulot pour remettre en ordre... mais c'est vrai qu'il pourrait être un peu facilité.
Que les sources ne contiennent que la partie concernant l'exécutable à compiler je trouve ça plutot bien. Car au niveau des paquets on préfère en faire plusieurs : un avec les données et un avec les exécutables. En effet les données représentent un gros volume, mais n'ont pas de compilation, et donc ne dépendent pas de l'achitecture (i386, x86_64, ppc...). Donc ce gros paquet à l'avantage d'être commun et seul un plus petit paquet est à décliner pour chaque cpu.

Par contre un truc tout bête mais l'archive contenant les sources m'avait embeter telle qu'elle est faite... Au lieu d'une archive nommée Sources_Client_1_5.zip contenant un dossier "sources", il m'aurait fallut un dossier du meme nom que l'archive (sans l'extension bien sur), celle-ci nommée avec le nom et la version du package, comme par exemple LandesEternelles-1.5.0.zip (ou .tar.gz aussi mais bon). Finalement en apprenant plus profondément sur le construction des paquets, j'ai pu trouver des options me permettant de faire avec...

et la makefile contenir une sources make install pour pouvoir étre installer facilement

Mouaip j'ai pleurer sur le coup en voyant qu'il n'y avait pas de make install dans le Makefile... Et puis bon encore une fois, les paquets sont aussi fait pour placer les fichiers à droite à gauche, donc on peut s'en passer sans problème. Finalement ça m'apporte de la souplesse pour décider où vont les choses simplement. Sinon faudrait un make install bien foutu qui utilise des prefixes paramétrables (enfin un seul est nécessaire après tout). Ca serait toujours un plus pourquoi pas (je m'y connais pas vraiment en Makefile, mais je regarderai pt'être ça à l'occaz)...


Voilà mon avis, enfin mon retour d'expérience surtout. En effet c'est pas nickel pour s'adapter proprement dans l'environnement mais on peut y arriver. J'ai pas remis le nez dans mon packaging qui est encore à améliorer, mais j'ai déjà un résultat que je trouve assez satisfaisant.

La prochaine étape que je compte entreprendre, c'est tester la construction de mon paquet sur une autre archi (je peux tester aussi sur ppc). Afin de voir si le même source RPM permet facilement d'obtenir les différents RPM binaires... Là j'ai un peu peur d'avoir quelques difficultés pour que le bon makefile soit utilisé, l'exécutable bien nommé... Mais bon rien d'insurmontable je pense. Je tiendrai informé dans le post que j'ai cité au début.