Lea Linux - Contributions [fr]

Logithèque Jeux

2005-12-18T12:54:36Z

CHiPs : /* Battle for Wesnoth */

==Jeux==

Auparavant, il y avait peu de jeux fonctionnant sous Linux, heureusement cet état de fait est en train de changer, et nous avons accès à une logithèque de plus en plus fournie.<br />

Certains sont commerciaux, mais vu la dépense que nécessite la réalisation de certains jeux et le nombre de personnes impliquées (programmeurs, graphistes, acteurs, etc.), la gratuité me semble illusoire. Bref, n'hurlez pas au loup, mais je pense que si les Linuxiens payaient autant leur jeux que les utilisateurs des OS Microsoft, cela faciliterait les choses... '''Libre''' ne signifie pas forcément gratuit, et encore moins radin !

Les [[Logithèque:Oldrub=2|émulateurs (voir rubrique correspondante de la logithèque)]] fournissent aussi des jeux en général passionants...

Le site [http://jeuxlibres.net/ JeuxLibres.net] recense également de nombreux jeux libres, avec fiche, captures d'écran et commentaires.

===Navigation dans les logiciels===
* [[Logithèque:Index|Retour à l'index]]
* [[Logithèque:Stratégie]]
* [[Logithèque:Casse-têtes]]
* [[Logithèque:Simulation]]
* [[Logithèque:Plate-forme]]
* [[Logithèque:Action / Baston]]
* [[Logithèque:Sports]]
* [[Logithèque:Arcade]]
* [[Logithèque:Jeux de rôle]]

===Liste des logiciels [Jeux]===

====Battle for Wesnoth====

Un superbe jeu à la Heroes , où le joueur doit créer son armée , selon les ressources qu'il arrive à engranger sur la carte et selon les capacitées de son château fort (qu'il peut bien sûr améliorer).
L'univers du jeux est l'heroic-fantasy, l'histoire est génialement bien faite, bref un MUST.

<strong>ATTENTION :</strong> le jeu est très très prenant. ;-p
* [http://wesnoth.org/ http://wesnoth.org/]
* [http://wesnoth.org/images/sshots/wesnoth-0.8.4-halo.jpg Copie d'écran]

====BzTarot====
La version Linux de de Bztarot est un partenaire toujours prêt à jouer au tarot à 4.
<br />
Jeu récement porté depuis Windows/Delphi en Kylix, premier logiciel libre (GPL) d'un récent converti à la linuxmania.
* [http://www.beuselinck.com http://www.beuselinck.com]
* [http://www.vbeuselinck.freesurf.fr/linux/capture.jpg Copie d'écran]

====DROD====
Deadly Rooms Of Death: rogue like très sympathique qui tiendra en éveil vos méninges pendant de longues nuits
* [http://www.drod.net http://www.drod.net]
* [http://www.drod.net/Screenshots/Images/DROD3D/Death1.jpg Copie d'écran]

====FreeSCI====
FreeSCI est un interpréteur pour les jeux écrits pour le système SCI de Sierra On-Line. ( Leisure Suit Larry 2,
Leisure Suit Larry 3, Police Quest 2, King's Quest 4, Hero's Quest / Quest for Glory 1, Space Quest 3, The Colonel's Bequest, Conquests of Camelot, Codename: Iceman, Hoyle's Book of Games, Hoyle's Book of Games 2 )
* [http://freesci.linuxgames.com/ http://freesci.linuxgames.com/]
* [http://freesci.linuxgames.com/screenshots/camelot-end.png Copie d'écran]

====Iatax====
Un clone d'Ataxx dans lequel les joueurs sont invités à créer leur propre bot.
* [http://iatax.sf.net/page_fr.html http://iatax.sf.net/page_fr.html]
Malheureusement, le projet n'est actuellement plus actif à cause du manque de temps de son créateur ...

====Loki====
Loki est une société qui convertit des jeux Windows sous Linux.<br />

Loki supporte le libre et diffuse de nombreux outils sous la license GPL (par exemple la librairie SMpeg). Achetez leurs jeux pour les aider !
<u>Mise à jour</u> : malheureusement Loki a déposé le bilan, après plusieurs années de contributions (SDL, Open AL...) au monde du libre. Merci à eux de nous avoir soutenu.
* [http://www.lokigames.com/ http://www.lokigames.com/]

====MGounki====
MGounki est un programme qui joue au Gounki développé en C++ sous Linux/GNU et distribué sous licence GNU GPL. Il fonctionne en mode texte, mais une passerelle a été développée en java pour lui permettre de jouer en mode graphique sur Internet.<br />

Le gounki est un jeu de réflexion pour deux joueurs facile à apprendre, et dont les parties sont animées et très rapides (moins de 20 coups en général). Il se joue sur un échiquier au moyen de pièces rondes et carrées, qui peuvent être empilées pour former des combinaisons. Le but du jeu est, pour chaque camp, d'amener une pièce (ou une combinaison) de sa couleur au-delà de la dernière rangée de l'échiquier.
* [http://perso.wanadoo.fr/rvo/gounki/ai.html http://perso.wanadoo.fr/rvo/gounki/ai.html]
* [http://www.gounki.org http://www.gounki.org]

====Open Warfare====
Un jeu GPL inspiré du jeu de plateau Warhammer 40k, tout en 3D.
* [http://openwarfare.sunsite.dk/index.html http://openwarfare.sunsite.dk/index.html]
* [http://openwarfare.sunsite.dk/screens/5.jpg Copie d'écran]

====Score Tarot====
Score Tarot est un logiciel permettant de compter les points au tarot, de réaliser des statistiques sur la partie en cours ou sur toutes les parties précédemment jouées. Vous pourrez également enregistrer la partie dans un fichier et la reprendre ensuite.
* [http://scoretarot.tuxfamily.org http://scoretarot.tuxfamily.org]
* [http://scoretarot.tuxfamily.org/uploads/photos/3.jpg Copie d'écran]

====ScummVM====
Interpréteur SCUMM (jeux de Lucas) pour Linux : Monkey Island, Indiana Jones, Maniac Mansion, Day Of The Tentacle, Sam and Max hit the road... revivent sous votre OS préféré (nécessite le jeu original) !
* [http://scummvm.org/ http://scummvm.org/]
* [http://scummvm.org/screenshots.php?view=big_scummvm_3&x= Day of the Tentacle]
* [http://www.scummvm.org/screenshots.php?view=big_scummvm_1&x=0 Sam'n Max]

====simutrans====
simulation de logistique (en cours de développement) : transport de matières et personnes par route et trains. Lancer simutrans -freeplay pour apprendre. (version semi française)
* [http://www.simutrans.de http://www.simutrans.de]

====SuperTux====
SuperTux est un clone de Super Mario dans lequel vous incarnez Tux, notre pingouin préféré. 26 niveaux s'offrent à vous, ainsi qu'une multitude de niveaux bonus.
* [http://supertux.berlios.de/ Site officiel]
* [http://supertux.berlios.de/screenshots.html Captures d'écran]

====tarotclub====
Un petit jeu de tarot Open source
* [http://tarotclub.ooso.org http://tarotclub.ooso.org]
* [http://tarotclub.ooso.org/gallery/1078868285.jpg Copie d'écran]

====xu4====
Grand classique des jeux de rôle. Ultima 4 fut créé en 1988 (ms-dos) et est toujours aussi populaire aujourd'hui.<br />

XU4 est un projet qui permet de porter ce jeu Ms-dos sur linux.<br />

Le jeu est en englais.<br />

* [http://xu4.sourceforge.net/ http://xu4.sourceforge.net/]
* [http://xu4.sourceforge.net/images/codex.png Copie d'écran]

P.S. : Je vous conseille grandement d'utiliser l'extension qui améliore les graphiques.

=== Voir aussi ===

* [http://www.linux-gamers.net/index.php Linux-gamers.net]
* [http://www.happypenguin.org/ The Linux Game Tome]

JPackage

2005-10-23T00:07:20Z

CHiPs : /* Ajout de jpackage, section nonfree, pour Mandrivalinux */

[[Category:Développer sous Linux]]
= Utilisation de Java grâce à Jpackage.org =

<div class="leatitre">Utilisation de Java grâce à Jpackage.org</div><div class="leapar">par [mailto:misc@zarb.org Mickael]</div><div class="leadesc">Installez proprement Java sur une distribution à base de RPM</div>

Le Java, ''saimalsaiproprioetsaipalibre'', mais souvent on a besoin de l'utiliser, pour tout un tas de bonnes raisons. De plus, il existe de très bons logiciels libres écrits en Java, et il fait partie des langages les plus utilisés par [http://apache.org l'ASF (Apache Software Foundation]. Malheureusement, il y a rarement des paquets de logiciels Java, car il nécessite une JVM, une machine virtuelle Java, une espèce d'interpréteur de code assembleur d'un processeur qui n'existe pas (voir [http://fr.wikipedia.org/wiki/Java_%28langage%29 Wikipedia] pour une description plus détaillée et sans doute plus claire).

Et c'est précisément la le problème, la plupart des JVMs ne sont pas libres, donc les distributions ne les incluent pas. Quand aux JVMs libres, elles ne sont pas assez performantes, aussi bien au niveau de la rapidité d'éxecution que du support du language. Quand un distributeur inclue un paquet de JVM, il met peu de programmes Java qui pourraient en bénéficier, et c'est dommage.

C'est la qu'intervient le projet [http://jpackage.org Jpackage]. Il s'agit d'un projet de distribution de RPMs de logiciels Java pour plusieurs distributions. Grâce à eux, installer Tomcat ou Jedit revient à simplement taper <code>urpmi jedit</code> ou <code>yum install tomcat4</code>. Ils proposent des paquets pour [http://www.mandrakelinux/ Mandrakelinux], [http://www.redhat.com/ Red Hat], [http://fedora.redhat.com Fedora], et d'autres distributions ( mais non testées ). Une fois le projet ajouté parmi vos sources de RPMs, vous pouvez donc accéder à [http://eclipse.org eclipse], à [http://ant.apache.org ant], et autres logiciels Java habituellement plus complexes à installer.

Toutefois, il reste le problème de la JVM. Malgré les efforts du projet et les tentatives de prise de contacts, Sun ( et les autres comme IBM, etc ) refusent de laisser des packageurs externes refaire leurs RPMs. Une solution a du être élaborée par les membres de Jpackage, que je vais expliquer dans ce document.

La problématique de base est la suivante : ''"Comment garder la cohérence du système de paquets lors qu'on veut utiliser des logiciels dans des paquets incorrects, non normalisés, ou inexistants ?"''. La réponse trouvée est de faire ou refaire les paquets. Cela permet de garantir une intégration correcte avec la distribution, d'être sur qu'on les retire sans problème, et d'être sur que tout ne seras pas cassé le jour ou le distributeur change tout, comme Sun semble le faire si souvent. Vous trouverez plus d'explications dans la [http://jpackage.org/faq.php FAQ du projet].

Ce document a été fait en testant sur une distribution Mandrakelinux 10.0, mais devrait être suffisamment générique pour d'autres distributions. N'hésitez à me faire parvenir vos contributions.

== Mise en oeuvre générale ==

Vous l'aurez compris, nous allons donc refaire les RPMs du JDK (Java Developer Kit, une JVM + un compilateur Java) afin de pouvoir utiliser jpackage. Le déroulement est le suivant :

* Préparation du home en vue de recompiler le RPM
* Récupération des archives et autres RPMs nécessaires
* Recompilation
* Ajout de jpackage comme média urpmi local

Le but à la fin étant de pouvoir utiliser urpmi ( ou yum, ou apt ) pour installer sans problème un logiciel comme [http://www.jext.org/ jext].

== Préparation du home pour la recompilation de RPM ==

Sans rentrer dans les détails, il existe deux types de RPM. Les RPM binaires, qu'on voit souvent, qui contiennent les logiciels compilés et prêts à l'emploi, et les RPM sources, qui sont utilisés pour faire les RPMs binaires. Un fichier RPM source, ou src.RPM est un RPM qui contient les sources d'un programme, plus des patches, d'autres fichiers, et un fichier de spécification RPM, appelé spec ( car son extension est .spec ). La moitié du travail pour faire un RPM consiste à écrire ce fichier, l'autre étant de faire marcher le spec comme il faut, et la troisième moitié étant de le tester, de coller aux règles de la distribution et de faire le support utilisateur et correction de bugs.

Pour faire un RPM, il existe quelques documentations ([http://www.rpm.org/RPM-HOWTO/ RPM.org], [http://qa.mandriva.com/twiki/bin/view/Main/RpmHowTo qa.mandriva.com], [http://www.linuxfrench.net/gnu_linux/distributions/mandrake/comment_faire_un_RPM_simplement..._article1327.html linuxfrench.net]), mais pour le cas qui nous intéresse (une "simple" recompilation), seul la partie préparation nous importe.

Pour résumer ces documents, il faut créer une arborescence spéciale destinée aux opérations de RPM dans votre répertoire personel et dire à RPM d'utiliser ces dossiers :

<div class="code">

$ mkdir -p ~/rpm/{RPMS/{i586,noarch},SRPMS,SPECS,tmp,BUILD,SOURCES}
$ cat << EOF > ~/.rpmmacros
%_topdir $HOME/rpm
%_tmppath /tmp
EOF

</div>

La dernière chose à faire, c'est d'installer le paquet rpm-build, afin d'avoir les fichiers pour recompiler un RPM.

<div class="code"><nowiki># urpmi rpm-build</nowiki></div>

== Récupération des divers archives et SRPM ==

Première étape, le fichier RPM source du JDK de Sun. Afin de montrer que c'est pas un fichier source comme les autres, il est appelé <code>java-1.4.2-sun-1.4.2.nosrc.rpm</code>. Il faut prendre le fichier source du paquet [http://jpackage.org/rpm.php?id=2879 java-1.4.2-sun-1.4.2].

En général, le SRPM contient les sources du paquet, mais le noeud du problème est justement que seul Sun peut les distribuer. Il faut donc les récupérer à part, sur le [http://java.sun.com/j2se/1.4.2/ site de sun] ( obtenu du champ Url du paquet ). Au moment de la rédaction de cette article, le chemin est :

<div class="note">Choisir "Download" , prendre "J2SE v 1.4.2_05 SDK ", accepter le formulaire après l'avoir lu, et enfin, choisir "Linux Platform", "self-extracting file" ( surtout pas "RPM in self-extracting file" mais bien "self-extracting file" ).</div>

Le fichier téléchargé de 30 Mo doit être déposé dans <code>~/rpm/SOURCES/</code>.

La dernière étape, c'est de d'installer le paquet <code>jpackage-utils</code>. Soit vous récupérez le paquet à la main, soit vous passez par urpmi. Pour l'installation à la main, le paquet est sur le [http://jpackage.org/rpm.php?id=2798 site de jpackage], ou sur les miroirs Mandrakelinux. Pour l'installer, <code> urpmi /le_chemin_vers_le_RPM</code> devrait suffire.

Pour l'installation via urpmi, [http://easyurpmi.zarb.org/ easy urpmi] doit avoir tout ce qu'il faut, il suffit d'ajouter 'jpackage', de la même façon que toutes les autres sources.

== Recompilation du RPM ==

Si tout va bien, vous devez être en mesure de recompiler le RPM. Vérifier que le fichier <code> j2sdk-1_4_2_04-linux-i586.bin</code> est dans <code>rpm/SOURCES</code>, et lancez la recompilation, avec la commande :

<div class="code">$ rpm --rebuild java-1.4.2-sun-1.4.2.05-3jpp.nosrc.rpm </div>

Le RPM va se charger d'accepter la licence que vous avez déjà acceptée au moment du téléchargement, et de répondre aux questions de l'installeur de Sun. À la fin, vous devriez voir ça :

<div class="code">Checking for unpackaged file(s): /usr/lib/rpm/check-files /tmp/java-1.4.2-sun-1.4.2.04-3jpp-buildroot<br /> Wrote: /home/users/misc/rpm/SRPMS/java-1.4.2-sun-1.4.2.04-3jpp.nosrc.rpm<br /> Wrote: /home/users/misc/rpm/RPMS/i586/java-1.4.2-sun-1.4.2.04-3jpp.i586.rpm<br /> Wrote: /home/users/misc/rpm/RPMS/i586/java-1.4.2-sun-devel-1.4.2.04-3jpp.i586.rpm<br /> Wrote: /home/users/misc/rpm/RPMS/i586/java-1.4.2-sun-src-1.4.2.04-3jpp.i586.rpm<br /> Wrote: /home/users/misc/rpm/RPMS/i586/java-1.4.2-sun-demo-1.4.2.04-3jpp.i586.rpm<br /> Wrote: /home/users/misc/rpm/RPMS/i586/java-1.4.2-sun-plugin-1.4.2.04-3jpp.i586.rpm<br /> Wrote: /home/users/misc/rpm/RPMS/i586/java-1.4.2-sun-fonts-1.4.2.04-3jpp.i586.rpm<br /> Wrote: /home/users/misc/rpm/RPMS/i586/java-1.4.2-sun-alsa-1.4.2.04-3jpp.i586.rpm<br /> Wrote: /home/users/misc/rpm/RPMS/i586/java-1.4.2-sun-jdbc-1.4.2.04-3jpp.i586.rpm<br /> Executing(%clean): /bin/sh -e /tmp/rpm-tmp.6627<br /> + umask 022<br /> + cd /home/users/misc/rpm/BUILD<br /> + cd j2sdk1.4.2_04<br /> + rm -rf /tmp/java-1.4.2-sun-1.4.2.04-3jpp-buildroot<br /> + exit 0</div>

Vous avez donc , dans rpm/RPMS/i586/ les RPMs de la JVM. Pour pouvoir exécuter des logiciels en Java, il vous faut java-1.4.2-sun. Le RPM java-1.4.2-sun-devel contient le compilateur et ce qu'il faut pour commencer à développer en Java. Enfin, java-1.4.2-sun-plugin est un plugin Java pour mozilla et konqueror.

== Ajout de jpackage, section nonfree, pour Mandrivalinux ==

Muni de vos RPMs, il va falloir les mettre quelque part pour les utiliser. Pour cela, le plus facile est d'ajouter une source locale pour votre gestionnaire de paquets. Copiez les RPMs dans le dossier de votre choix, on va dire <code>/var/local/urpmi/jpackage/</code>. Puis, il faut génerer les index à l'aide du programme genhdlist du paquet rpmtools. Enfin, vous devez ajouter la source à urpmi.

<div class="code"><nowiki># export DEST=/var/local/urpmi/jpackage/ </nowiki><br /> # mkdir -p $DEST <br /> # cp -R ~/rpm/RPMS/i586/java* $DEST <br /> # ( cd $DEST; genhdlist )<br /> # urpmi.addmedia jpackage_local file://$DEST with ./hdlist.cz </div>

Et voila, maintenant, <code>urpmi java-1.4.2</code> vous installera la JVM de Sun, et vous pouvez installer les RPMs de jpackage. Si vous préférez une autre JVM ou une autre version, vous pouvez procédez de la même manière. Les paquets sont normalement installables cote à cote en parallèle.

<div class="merci">Cette page est issue de la documentation 'pré-wiki' de Léa a été convertie avec HTML::WikiConverter. Elle fut créée par Mickael Scherer le 25/07/2004.</div>

= Copyright =
Copyright © 25/07/2004, Mickael Scherer
{{CC-BY-NC-SA}}

JPackage

2005-10-23T00:05:13Z

CHiPs : /* Mise en oeuvre général */

[[Category:Développer sous Linux]]
= Utilisation de Java grâce à Jpackage.org =

<div class="leatitre">Utilisation de Java grâce à Jpackage.org</div><div class="leapar">par [mailto:misc@zarb.org Mickael]</div><div class="leadesc">Installez proprement Java sur une distribution à base de RPM</div>

Le Java, ''saimalsaiproprioetsaipalibre'', mais souvent on a besoin de l'utiliser, pour tout un tas de bonnes raisons. De plus, il existe de très bons logiciels libres écrits en Java, et il fait partie des langages les plus utilisés par [http://apache.org l'ASF (Apache Software Foundation]. Malheureusement, il y a rarement des paquets de logiciels Java, car il nécessite une JVM, une machine virtuelle Java, une espèce d'interpréteur de code assembleur d'un processeur qui n'existe pas (voir [http://fr.wikipedia.org/wiki/Java_%28langage%29 Wikipedia] pour une description plus détaillée et sans doute plus claire).

Et c'est précisément la le problème, la plupart des JVMs ne sont pas libres, donc les distributions ne les incluent pas. Quand aux JVMs libres, elles ne sont pas assez performantes, aussi bien au niveau de la rapidité d'éxecution que du support du language. Quand un distributeur inclue un paquet de JVM, il met peu de programmes Java qui pourraient en bénéficier, et c'est dommage.

C'est la qu'intervient le projet [http://jpackage.org Jpackage]. Il s'agit d'un projet de distribution de RPMs de logiciels Java pour plusieurs distributions. Grâce à eux, installer Tomcat ou Jedit revient à simplement taper <code>urpmi jedit</code> ou <code>yum install tomcat4</code>. Ils proposent des paquets pour [http://www.mandrakelinux/ Mandrakelinux], [http://www.redhat.com/ Red Hat], [http://fedora.redhat.com Fedora], et d'autres distributions ( mais non testées ). Une fois le projet ajouté parmi vos sources de RPMs, vous pouvez donc accéder à [http://eclipse.org eclipse], à [http://ant.apache.org ant], et autres logiciels Java habituellement plus complexes à installer.

Toutefois, il reste le problème de la JVM. Malgré les efforts du projet et les tentatives de prise de contacts, Sun ( et les autres comme IBM, etc ) refusent de laisser des packageurs externes refaire leurs RPMs. Une solution a du être élaborée par les membres de Jpackage, que je vais expliquer dans ce document.

La problématique de base est la suivante : ''"Comment garder la cohérence du système de paquets lors qu'on veut utiliser des logiciels dans des paquets incorrects, non normalisés, ou inexistants ?"''. La réponse trouvée est de faire ou refaire les paquets. Cela permet de garantir une intégration correcte avec la distribution, d'être sur qu'on les retire sans problème, et d'être sur que tout ne seras pas cassé le jour ou le distributeur change tout, comme Sun semble le faire si souvent. Vous trouverez plus d'explications dans la [http://jpackage.org/faq.php FAQ du projet].

Ce document a été fait en testant sur une distribution Mandrakelinux 10.0, mais devrait être suffisamment générique pour d'autres distributions. N'hésitez à me faire parvenir vos contributions.

== Mise en oeuvre générale ==

Vous l'aurez compris, nous allons donc refaire les RPMs du JDK (Java Developer Kit, une JVM + un compilateur Java) afin de pouvoir utiliser jpackage. Le déroulement est le suivant :

* Préparation du home en vue de recompiler le RPM
* Récupération des archives et autres RPMs nécessaires
* Recompilation
* Ajout de jpackage comme média urpmi local

Le but à la fin étant de pouvoir utiliser urpmi ( ou yum, ou apt ) pour installer sans problème un logiciel comme [http://www.jext.org/ jext].

== Préparation du home pour la recompilation de RPM ==

Sans rentrer dans les détails, il existe deux types de RPM. Les RPM binaires, qu'on voit souvent, qui contiennent les logiciels compilés et prêts à l'emploi, et les RPM sources, qui sont utilisés pour faire les RPMs binaires. Un fichier RPM source, ou src.RPM est un RPM qui contient les sources d'un programme, plus des patches, d'autres fichiers, et un fichier de spécification RPM, appelé spec ( car son extension est .spec ). La moitié du travail pour faire un RPM consiste à écrire ce fichier, l'autre étant de faire marcher le spec comme il faut, et la troisième moitié étant de le tester, de coller aux règles de la distribution et de faire le support utilisateur et correction de bugs.

Pour faire un RPM, il existe quelques documentations ([http://www.rpm.org/RPM-HOWTO/ RPM.org], [http://qa.mandriva.com/twiki/bin/view/Main/RpmHowTo qa.mandriva.com], [http://www.linuxfrench.net/gnu_linux/distributions/mandrake/comment_faire_un_RPM_simplement..._article1327.html linuxfrench.net]), mais pour le cas qui nous intéresse (une "simple" recompilation), seul la partie préparation nous importe.

Pour résumer ces documents, il faut créer une arborescence spéciale destinée aux opérations de RPM dans votre répertoire personel et dire à RPM d'utiliser ces dossiers :

<div class="code">

$ mkdir -p ~/rpm/{RPMS/{i586,noarch},SRPMS,SPECS,tmp,BUILD,SOURCES}
$ cat << EOF > ~/.rpmmacros
%_topdir $HOME/rpm
%_tmppath /tmp
EOF

</div>

La dernière chose à faire, c'est d'installer le paquet rpm-build, afin d'avoir les fichiers pour recompiler un RPM.

<div class="code"><nowiki># urpmi rpm-build</nowiki></div>

== Récupération des divers archives et SRPM ==

Première étape, le fichier RPM source du JDK de Sun. Afin de montrer que c'est pas un fichier source comme les autres, il est appelé <code>java-1.4.2-sun-1.4.2.nosrc.rpm</code>. Il faut prendre le fichier source du paquet [http://jpackage.org/rpm.php?id=2879 java-1.4.2-sun-1.4.2].

En général, le SRPM contient les sources du paquet, mais le noeud du problème est justement que seul Sun peut les distribuer. Il faut donc les récupérer à part, sur le [http://java.sun.com/j2se/1.4.2/ site de sun] ( obtenu du champ Url du paquet ). Au moment de la rédaction de cette article, le chemin est :

<div class="note">Choisir "Download" , prendre "J2SE v 1.4.2_05 SDK ", accepter le formulaire après l'avoir lu, et enfin, choisir "Linux Platform", "self-extracting file" ( surtout pas "RPM in self-extracting file" mais bien "self-extracting file" ).</div>

Le fichier téléchargé de 30 Mo doit être déposé dans <code>~/rpm/SOURCES/</code>.

La dernière étape, c'est de d'installer le paquet <code>jpackage-utils</code>. Soit vous récupérez le paquet à la main, soit vous passez par urpmi. Pour l'installation à la main, le paquet est sur le [http://jpackage.org/rpm.php?id=2798 site de jpackage], ou sur les miroirs Mandrakelinux. Pour l'installer, <code> urpmi /le_chemin_vers_le_RPM</code> devrait suffire.

Pour l'installation via urpmi, [http://easyurpmi.zarb.org/ easy urpmi] doit avoir tout ce qu'il faut, il suffit d'ajouter 'jpackage', de la même façon que toutes les autres sources.

== Recompilation du RPM ==

Si tout va bien, vous devez être en mesure de recompiler le RPM. Vérifier que le fichier <code> j2sdk-1_4_2_04-linux-i586.bin</code> est dans <code>rpm/SOURCES</code>, et lancez la recompilation, avec la commande :

<div class="code">$ rpm --rebuild java-1.4.2-sun-1.4.2.05-3jpp.nosrc.rpm </div>

Le RPM va se charger d'accepter la licence que vous avez déjà acceptée au moment du téléchargement, et de répondre aux questions de l'installeur de Sun. À la fin, vous devriez voir ça :

<div class="code">Checking for unpackaged file(s): /usr/lib/rpm/check-files /tmp/java-1.4.2-sun-1.4.2.04-3jpp-buildroot<br /> Wrote: /home/users/misc/rpm/SRPMS/java-1.4.2-sun-1.4.2.04-3jpp.nosrc.rpm<br /> Wrote: /home/users/misc/rpm/RPMS/i586/java-1.4.2-sun-1.4.2.04-3jpp.i586.rpm<br /> Wrote: /home/users/misc/rpm/RPMS/i586/java-1.4.2-sun-devel-1.4.2.04-3jpp.i586.rpm<br /> Wrote: /home/users/misc/rpm/RPMS/i586/java-1.4.2-sun-src-1.4.2.04-3jpp.i586.rpm<br /> Wrote: /home/users/misc/rpm/RPMS/i586/java-1.4.2-sun-demo-1.4.2.04-3jpp.i586.rpm<br /> Wrote: /home/users/misc/rpm/RPMS/i586/java-1.4.2-sun-plugin-1.4.2.04-3jpp.i586.rpm<br /> Wrote: /home/users/misc/rpm/RPMS/i586/java-1.4.2-sun-fonts-1.4.2.04-3jpp.i586.rpm<br /> Wrote: /home/users/misc/rpm/RPMS/i586/java-1.4.2-sun-alsa-1.4.2.04-3jpp.i586.rpm<br /> Wrote: /home/users/misc/rpm/RPMS/i586/java-1.4.2-sun-jdbc-1.4.2.04-3jpp.i586.rpm<br /> Executing(%clean): /bin/sh -e /tmp/rpm-tmp.6627<br /> + umask 022<br /> + cd /home/users/misc/rpm/BUILD<br /> + cd j2sdk1.4.2_04<br /> + rm -rf /tmp/java-1.4.2-sun-1.4.2.04-3jpp-buildroot<br /> + exit 0</div>

Vous avez donc , dans rpm/RPMS/i586/ les RPMs de la JVM. Pour pouvoir exécuter des logiciels en Java, il vous faut java-1.4.2-sun. Le RPM java-1.4.2-sun-devel contient le compilateur et ce qu'il faut pour commencer à développer en Java. Enfin, java-1.4.2-sun-plugin est un plugin Java pour mozilla et konqueror.

== Ajout de jpackage, section nonfree, pour Mandrivalinux ==

Muni de vos RPMs, il va falloir les mettre quelque part pour les utiliser. Pour cela, le plus facile est d'ajouter une source local pour votre gestionnaire de paquet. Copiez les RPMs dans le dossier de votre choix, on va dire <code> /var/local/urpmi/jpackage/</code>. Puis, il faut génerer les indexes à l'aide du programme genhdlist du paquet rpmtools. Enfin, vous devez ajouter la source à urpmi.

<div class="code"><nowiki># export DEST=/var/local/urpmi/jpackage/ </nowiki><br /> # mkdir -p $DEST <br /> # cp -R ~/rpm/RPMS/i586/java* $DEST <br /> # ( cd $DEST; genhdlist )<br /> # urpmi.addmedia jpackage_local file://$DEST with ./hdlist.cz </div>

Et voila, maintenant, <code> urpmi java-1.4.2</code> vous installera la JVM de Sun, et vous pouvez installer les RPMs de jpackage. Si vous préférez une autre JVM ou une autre version, vous pouvez procédez de la même manière. Les paquets sont normalement installables cote à cote en parallèle.

<div class="merci">Cette page est issue de la documentation 'pré-wiki' de Léa a été convertie avec HTML::WikiConverter. Elle fut créée par Mickael Scherer le 25/07/2004.</div>

= Copyright =
Copyright © 25/07/2004, Mickael Scherer
{{CC-BY-NC-SA}}

JPackage

2005-10-23T00:03:49Z

CHiPs : /* Utilisation de Java grâce à Jpackage.org */

[[Category:Développer sous Linux]]
= Utilisation de Java grâce à Jpackage.org =

<div class="leatitre">Utilisation de Java grâce à Jpackage.org</div><div class="leapar">par [mailto:misc@zarb.org Mickael]</div><div class="leadesc">Installez proprement Java sur une distribution à base de RPM</div>

Le Java, ''saimalsaiproprioetsaipalibre'', mais souvent on a besoin de l'utiliser, pour tout un tas de bonnes raisons. De plus, il existe de très bons logiciels libres écrits en Java, et il fait partie des langages les plus utilisés par [http://apache.org l'ASF (Apache Software Foundation]. Malheureusement, il y a rarement des paquets de logiciels Java, car il nécessite une JVM, une machine virtuelle Java, une espèce d'interpréteur de code assembleur d'un processeur qui n'existe pas (voir [http://fr.wikipedia.org/wiki/Java_%28langage%29 Wikipedia] pour une description plus détaillée et sans doute plus claire).

Et c'est précisément la le problème, la plupart des JVMs ne sont pas libres, donc les distributions ne les incluent pas. Quand aux JVMs libres, elles ne sont pas assez performantes, aussi bien au niveau de la rapidité d'éxecution que du support du language. Quand un distributeur inclue un paquet de JVM, il met peu de programmes Java qui pourraient en bénéficier, et c'est dommage.

C'est la qu'intervient le projet [http://jpackage.org Jpackage]. Il s'agit d'un projet de distribution de RPMs de logiciels Java pour plusieurs distributions. Grâce à eux, installer Tomcat ou Jedit revient à simplement taper <code>urpmi jedit</code> ou <code>yum install tomcat4</code>. Ils proposent des paquets pour [http://www.mandrakelinux/ Mandrakelinux], [http://www.redhat.com/ Red Hat], [http://fedora.redhat.com Fedora], et d'autres distributions ( mais non testées ). Une fois le projet ajouté parmi vos sources de RPMs, vous pouvez donc accéder à [http://eclipse.org eclipse], à [http://ant.apache.org ant], et autres logiciels Java habituellement plus complexes à installer.

Toutefois, il reste le problème de la JVM. Malgré les efforts du projet et les tentatives de prise de contacts, Sun ( et les autres comme IBM, etc ) refusent de laisser des packageurs externes refaire leurs RPMs. Une solution a du être élaborée par les membres de Jpackage, que je vais expliquer dans ce document.

La problématique de base est la suivante : ''"Comment garder la cohérence du système de paquets lors qu'on veut utiliser des logiciels dans des paquets incorrects, non normalisés, ou inexistants ?"''. La réponse trouvée est de faire ou refaire les paquets. Cela permet de garantir une intégration correcte avec la distribution, d'être sur qu'on les retire sans problème, et d'être sur que tout ne seras pas cassé le jour ou le distributeur change tout, comme Sun semble le faire si souvent. Vous trouverez plus d'explications dans la [http://jpackage.org/faq.php FAQ du projet].

Ce document a été fait en testant sur une distribution Mandrakelinux 10.0, mais devrait être suffisamment générique pour d'autres distributions. N'hésitez à me faire parvenir vos contributions.

== Mise en oeuvre général ==

Vous l'aurez compris, nous allons donc refaire les RPMs du JDK (Java Developer Kit, une JVM + un compilateur Java) afin de pouvoir utiliser jpackage. Le déroulement est le suivant :

* Préparation du home en vue de recompiler le RPM
* Récupération des archives et autres RPMs nécessaires
* Recompilation
* Ajout de jpackage comme média urpmi local

Le but à la fin étant de pouvoir utiliser urpmi ( ou yum, ou apt ) pour installer sans problème un logiciel comme [http://www.jext.org/ jext].

== Préparation du home pour la recompilation de RPM ==

Sans rentrer dans les détails, il existe deux types de RPM. Les RPM binaires, qu'on voit souvent, qui contiennent les logiciels compilés et prêts à l'emploi, et les RPM sources, qui sont utilisés pour faire les RPMs binaires. Un fichier RPM source, ou src.RPM est un RPM qui contient les sources d'un programme, plus des patches, d'autres fichiers, et un fichier de spécification RPM, appelé spec ( car son extension est .spec ). La moitié du travail pour faire un RPM consiste à écrire ce fichier, l'autre étant de faire marcher le spec comme il faut, et la troisième moitié étant de le tester, de coller aux règles de la distribution et de faire le support utilisateur et correction de bugs.

Pour faire un RPM, il existe quelques documentations ([http://www.rpm.org/RPM-HOWTO/ RPM.org], [http://qa.mandriva.com/twiki/bin/view/Main/RpmHowTo qa.mandriva.com], [http://www.linuxfrench.net/gnu_linux/distributions/mandrake/comment_faire_un_RPM_simplement..._article1327.html linuxfrench.net]), mais pour le cas qui nous intéresse (une "simple" recompilation), seul la partie préparation nous importe.

Pour résumer ces documents, il faut créer une arborescence spéciale destinée aux opérations de RPM dans votre répertoire personel et dire à RPM d'utiliser ces dossiers :

<div class="code">

$ mkdir -p ~/rpm/{RPMS/{i586,noarch},SRPMS,SPECS,tmp,BUILD,SOURCES}
$ cat << EOF > ~/.rpmmacros
%_topdir $HOME/rpm
%_tmppath /tmp
EOF

</div>

La dernière chose à faire, c'est d'installer le paquet rpm-build, afin d'avoir les fichiers pour recompiler un RPM.

<div class="code"><nowiki># urpmi rpm-build</nowiki></div>

== Récupération des divers archives et SRPM ==

Première étape, le fichier RPM source du JDK de Sun. Afin de montrer que c'est pas un fichier source comme les autres, il est appelé <code>java-1.4.2-sun-1.4.2.nosrc.rpm</code>. Il faut prendre le fichier source du paquet [http://jpackage.org/rpm.php?id=2879 java-1.4.2-sun-1.4.2].

En général, le SRPM contient les sources du paquet, mais le noeud du problème est justement que seul Sun peut les distribuer. Il faut donc les récupérer à part, sur le [http://java.sun.com/j2se/1.4.2/ site de sun] ( obtenu du champ Url du paquet ). Au moment de la rédaction de cette article, le chemin est :

<div class="note">Choisir "Download" , prendre "J2SE v 1.4.2_05 SDK ", accepter le formulaire après l'avoir lu, et enfin, choisir "Linux Platform", "self-extracting file" ( surtout pas "RPM in self-extracting file" mais bien "self-extracting file" ).</div>

Le fichier téléchargé de 30 Mo doit être déposé dans <code>~/rpm/SOURCES/</code>.

La dernière étape, c'est de d'installer le paquet <code>jpackage-utils</code>. Soit vous récupérez le paquet à la main, soit vous passez par urpmi. Pour l'installation à la main, le paquet est sur le [http://jpackage.org/rpm.php?id=2798 site de jpackage], ou sur les miroirs Mandrakelinux. Pour l'installer, <code> urpmi /le_chemin_vers_le_RPM</code> devrait suffire.

Pour l'installation via urpmi, [http://easyurpmi.zarb.org/ easy urpmi] doit avoir tout ce qu'il faut, il suffit d'ajouter 'jpackage', de la même façon que toutes les autres sources.

== Recompilation du RPM ==

Si tout va bien, vous devez être en mesure de recompiler le RPM. Vérifier que le fichier <code> j2sdk-1_4_2_04-linux-i586.bin</code> est dans <code>rpm/SOURCES</code>, et lancez la recompilation, avec la commande :

<div class="code">$ rpm --rebuild java-1.4.2-sun-1.4.2.05-3jpp.nosrc.rpm </div>

Le RPM va se charger d'accepter la licence que vous avez déjà acceptée au moment du téléchargement, et de répondre aux questions de l'installeur de Sun. À la fin, vous devriez voir ça :

<div class="code">Checking for unpackaged file(s): /usr/lib/rpm/check-files /tmp/java-1.4.2-sun-1.4.2.04-3jpp-buildroot<br /> Wrote: /home/users/misc/rpm/SRPMS/java-1.4.2-sun-1.4.2.04-3jpp.nosrc.rpm<br /> Wrote: /home/users/misc/rpm/RPMS/i586/java-1.4.2-sun-1.4.2.04-3jpp.i586.rpm<br /> Wrote: /home/users/misc/rpm/RPMS/i586/java-1.4.2-sun-devel-1.4.2.04-3jpp.i586.rpm<br /> Wrote: /home/users/misc/rpm/RPMS/i586/java-1.4.2-sun-src-1.4.2.04-3jpp.i586.rpm<br /> Wrote: /home/users/misc/rpm/RPMS/i586/java-1.4.2-sun-demo-1.4.2.04-3jpp.i586.rpm<br /> Wrote: /home/users/misc/rpm/RPMS/i586/java-1.4.2-sun-plugin-1.4.2.04-3jpp.i586.rpm<br /> Wrote: /home/users/misc/rpm/RPMS/i586/java-1.4.2-sun-fonts-1.4.2.04-3jpp.i586.rpm<br /> Wrote: /home/users/misc/rpm/RPMS/i586/java-1.4.2-sun-alsa-1.4.2.04-3jpp.i586.rpm<br /> Wrote: /home/users/misc/rpm/RPMS/i586/java-1.4.2-sun-jdbc-1.4.2.04-3jpp.i586.rpm<br /> Executing(%clean): /bin/sh -e /tmp/rpm-tmp.6627<br /> + umask 022<br /> + cd /home/users/misc/rpm/BUILD<br /> + cd j2sdk1.4.2_04<br /> + rm -rf /tmp/java-1.4.2-sun-1.4.2.04-3jpp-buildroot<br /> + exit 0</div>

Vous avez donc , dans rpm/RPMS/i586/ les RPMs de la JVM. Pour pouvoir exécuter des logiciels en Java, il vous faut java-1.4.2-sun. Le RPM java-1.4.2-sun-devel contient le compilateur et ce qu'il faut pour commencer à développer en Java. Enfin, java-1.4.2-sun-plugin est un plugin Java pour mozilla et konqueror.

== Ajout de jpackage, section nonfree, pour Mandrivalinux ==

Muni de vos RPMs, il va falloir les mettre quelque part pour les utiliser. Pour cela, le plus facile est d'ajouter une source local pour votre gestionnaire de paquet. Copiez les RPMs dans le dossier de votre choix, on va dire <code> /var/local/urpmi/jpackage/</code>. Puis, il faut génerer les indexes à l'aide du programme genhdlist du paquet rpmtools. Enfin, vous devez ajouter la source à urpmi.

<div class="code"><nowiki># export DEST=/var/local/urpmi/jpackage/ </nowiki><br /> # mkdir -p $DEST <br /> # cp -R ~/rpm/RPMS/i586/java* $DEST <br /> # ( cd $DEST; genhdlist )<br /> # urpmi.addmedia jpackage_local file://$DEST with ./hdlist.cz </div>

Et voila, maintenant, <code> urpmi java-1.4.2</code> vous installera la JVM de Sun, et vous pouvez installer les RPMs de jpackage. Si vous préférez une autre JVM ou une autre version, vous pouvez procédez de la même manière. Les paquets sont normalement installables cote à cote en parallèle.

<div class="merci">Cette page est issue de la documentation 'pré-wiki' de Léa a été convertie avec HTML::WikiConverter. Elle fut créée par Mickael Scherer le 25/07/2004.</div>

= Copyright =
Copyright © 25/07/2004, Mickael Scherer
{{CC-BY-NC-SA}}

Confid

2005-10-21T23:09:10Z

CHiPs : /* Contributions */

== Confidentialité ==

=== Cookies ===

Le site Léa (lea-linux.org) utilise des cookies permettant notamment de vous identifier dans les forums. Vous pouvez désactiver ces cookies, néanmoins la navigation dans les forums peut être moins aisée.

=== Modération ===

Un modérateur est susceptible de supprimer, préalablement ou postérieurement à sa diffusion, toute contribution (forums, logithèque, trucs et astuces, driverthèque...) qui ne serait pas en relation avec le thème de discussion abordé, la ligne éditoriale du site, ou qui serait contraire à la loi.

=== Contributions ===

Léa se réserve le droit de refuser toute contribution (article, truc & astuce, logiciel dans la logithèque, etc.) dont l'esprit, le contenu et/ou la licence serait en contradiction avec la ligne éditoriale du site et/ou la licence des autres articles.

=== Informations personnelles ===

Les adresses électroniques collectées par Léa (forums, listes de diffusion, etc.) ne sont pas utilisées par Léa dans un but commercial, ni redistribuées par Léa à des tiers.

Lorsque nous affichons une adresse, celle-ci est en général "cryptée" afin d'empêcher les robots qui parcourent le web afin de constituer des bases de données d'adresses, à des fins publicitaires. Par exemple, l'adresse "jice chez lea-linux point org" se lit en remplaçant "chez" par "@" et "point" par ".".

Conformément à la loi française n°78-17 du 6 janvier 1978 concernant l'information électronique, les fichiers de données et la liberté, et les recommendations de la Commission Nationale de l'Informatique et des Libertés ([http://www.cnil.fr CNIL]), Léa vous informe que :

* Télécharger des données depuis le site de Léa afin de constituer ou enrichir une base de données contenant des informations personnelles (par exemple des adresses électroniques) est strictement interdit, ainsi que leur utilisation pour des buts commerciaux ou publicitaires.
* Le droit d'accès, de modification et de suppression des données personnelles vous concernant, gérées sur le site web Léa, vous est garanti (art. 34 de la loi n°78-17).<br /> Ce droit d'accès, de modification ou de suppression d'informations personnelles vous concernant peut être exercé en contactant :<br /> Association Léa<br /> c.o. JC Cardot<br /> 24 avenue Faidherbe<br /> 92600 Asnieres - France<br /> adresse électronique : jice chez lea-linux point org (Remplacer "chez" par "@" et "point" par "." afin d'obtenir l'adresse électronique. Cet artifice est utilisé pour protéger l'adresse électronique des robots qui parcourent le web afin de constituer des bases de données d'adresses, à des fins publicitaires).

<div class="merci">Cette page est issue de la documentation 'pré-wiki' de Léa a été convertie avec HTML::WikiConverter. Elle fut créée par Jean-Christophe Cardot le 02/07/2003.</div>

= Copyright =
Copyright © 02/07/2003, Jean-Christophe Cardot
{{CC-BY-NC-SA}}