« JPackage » : différence entre les versions

De Lea Linux
Aller à la navigation Aller à la recherche
(balises code)
(6 versions intermédiaires par 4 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
[[Category:Développer sous Linux]]
[[Catégorie:Développement]]
 
= Utilisation de Java grâce à Jpackage.org =
= 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>
<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).
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 ils nécessitent 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.
Et c'est précisément le problème : la plupart des JVMs ne sont pas libres, donc les distributions ne les incluent pas. Quant 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 inclut 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.
C'est 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 <span class="code">urpmi jedit</span> ou <span class="code">yum install tomcat4</span>. Ils proposent des paquets pour [http://www.mandriva.com/ Mandriva], [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.
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 ê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].
La problématique de base est la suivante : ''"Comment garder la cohérence du système de paquets lorsqu'on veut utiliser des logiciels distribués 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 sûr qu'on les retire sans problème, et d'être sûr que tout ne sera pas cassé le jour 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.
Ce document a été fait en testant sur une distribution Mandivalinux 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 ==
== 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 :
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 :
Ligne 25 : Ligne 26 :
* Ajout de jpackage comme média urpmi local
* 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].
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 ==
== 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.
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 la 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 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), seule 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 :
Pour résumer ces documents, il faut créer une arborescence spéciale destinée aux opérations de RPM dans votre répertoire personnel et dire à RPM d'utiliser ces dossiers :


<div class="code">
<div class="code">
Ligne 51 : Ligne 52 :
== Récupération des divers archives et SRPM ==
== 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].
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é <span class="code">java-1.4.2-sun-1.4.2.nosrc.rpm</span>. 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 :
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 cet 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>
<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>.
Le fichier téléchargé (de 30 Mo) doit être déposé dans <span class="code">~/rpm/SOURCES/</span>.


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.
La dernière étape, c'est d'installer le paquet <span class="code">jpackage-utils</span>. 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 Mandriva. Pour l'installer, <span class="code">urpmi /le_chemin_vers_le_RPM</span> 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.
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.
Ligne 65 : Ligne 66 :
== Recompilation du RPM ==
== 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 :
Si tout va bien, vous devez être en mesure de recompiler le RPM. Vérifiez que le fichier <span class="code">j2sdk-1_4_2_04-linux-i586.bin</span> est dans <span class="code">rpm/SOURCES</span>, 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>
<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 :
Le RPM va se charger d'accepter la licence que vous avez déjà accepté 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>
<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>
Ligne 77 : Ligne 78 :
== Ajout de jpackage, section nonfree, pour Mandrivalinux ==
== 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.
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 <span class="code">/var/local/urpmi/jpackage/</span>. Puis, il faut génerer les index à l'aide du programme genhdlist du paquet rpmtools. Enfin, vous devez ajouter la source à urpmi.
 
<span class="code"><nowiki>#</nowiki>export DEST=/var/local/urpmi/jpackage
<nowiki>#</nowiki>mkdir -p $DEST
<nowiki>#</nowiki>cp -R ~/rpm/RPMS/i586/java* $DEST
<nowiki>#</nowiki>( cd $DEST; genhdlist )
<nowiki>#</nowiki>urpmi.addmedia jpackage_local file://$DEST with ./hdlist.cz</span>
 
Et voilà, maintenant, <span class="code">urpmi java-1.4.2</span> 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éder de la même manière. Les paquets sont normalement installables côte à côte en parallèle.


<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>
<br/>
<br/>
'''<b>[[Dev-index|@ Retour à la rubrique Développement]]</b>'''
<br/>


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


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

Version du 5 juin 2012 à 17:58


Utilisation de Java grâce à Jpackage.org

Utilisation de Java grâce à Jpackage.org
Installez proprement Java sur une distribution à base de RPM

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 l'ASF (Apache Software Foundation). Malheureusement, il y a rarement des paquets de logiciels Java, car ils nécessitent une JVM, une machine virtuelle Java, une espèce d'interpréteur de code assembleur d'un processeur qui n'existe pas (voir Wikipedia pour une description plus détaillée et sans doute plus claire).

Et c'est précisément là le problème : la plupart des JVMs ne sont pas libres, donc les distributions ne les incluent pas. Quant 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 inclut un paquet de JVM, il met peu de programmes Java qui pourraient en bénéficier, et c'est dommage.

C'est là qu'intervient le projet 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 urpmi jedit ou yum install tomcat4. Ils proposent des paquets pour Mandriva, Red Hat, Fedora, et d'autres distributions (mais non testées). Une fois le projet ajouté parmi vos sources de RPMs, vous pouvez donc accéder à eclipse, à 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 dû ê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 lorsqu'on veut utiliser des logiciels distribués 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 sûr qu'on les retire sans problème, et d'être sûr que tout ne sera pas cassé le jour où le distributeur change tout, comme Sun semble le faire si souvent. Vous trouverez plus d'explications dans la FAQ du projet.

Ce document a été fait en testant sur une distribution Mandivalinux 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 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 la correction de bugs.

Pour faire un RPM, il existe quelques documentations (RPM.org, qa.mandriva.com, linuxfrench.net), mais pour le cas qui nous intéresse (une "simple" recompilation), seule 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 personnel et dire à RPM d'utiliser ces dossiers :

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

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

# urpmi rpm-build

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é java-1.4.2-sun-1.4.2.nosrc.rpm. Il faut prendre le fichier source du paquet 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 site de sun (obtenu du champ Url du paquet). Au moment de la rédaction de cet article, le chemin est :

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" ).

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

La dernière étape, c'est d'installer le paquet jpackage-utils. Soit vous récupérez le paquet à la main, soit vous passez par urpmi. Pour l'installation à la main, le paquet est sur le site de jpackage, ou sur les miroirs Mandriva. Pour l'installer, urpmi /le_chemin_vers_le_RPM devrait suffire.

Pour l'installation via urpmi, 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érifiez que le fichier j2sdk-1_4_2_04-linux-i586.bin est dans rpm/SOURCES, et lancez la recompilation, avec la commande :

$ rpm --rebuild java-1.4.2-sun-1.4.2.05-3jpp.nosrc.rpm

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

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

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 /var/local/urpmi/jpackage/. Puis, il faut génerer les index à l'aide du programme genhdlist du paquet rpmtools. Enfin, vous devez ajouter la source à urpmi.

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

Et voilà, maintenant, urpmi java-1.4.2 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éder de la même manière. Les paquets sont normalement installables côte à côte en parallèle.



@ Retour à la rubrique Développement


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

Copyright

Copyright © 25/07/2004, Mickael Scherer

Creative Commons License
Creative Commons Attribution iconCreative Commons Share Alike iconCreative Commons Noncommercial
Ce document est publié sous licence Creative Commons
Attribution, Partage à l'identique, Contexte non commercial 2.0 :
http://creativecommons.org/licenses/by-nc-sa/2.0/fr/