Une question que je me pose depuis longtemps et qui me devient cruciale
maintenant que je tente de faire un livecd le plus r=E9duit possible tout
en contenant un maximum d'application.
J'ai sur mon syst=E8me, install=E9s, blackdown-jre et blackdown-jdk.
Sans aucun doute =E0 cause des uses java des diff=E9rents openoffice et
mozilla-firefox (entre autres).
Mais cela ne fait-il pas double emploi d'autant que ce sont quand m=EAme =
de
tr=E8s gros packages ?
En effet, dans le jdk, je vois un r=E9pertoire jre.
N'est-il pas possible de supprimer (pas d'installer par emerge car il va
virer les plugin mozilla avec) carr=E9ment jre et de faire un lien
symbolique de backdown-jdk/jre vers blackdown-jre ?
Je suis preneur de toute solution me permettant d'en virer l'un des 2,
sans toutefois perdre l'usage de java dans une application.
Merci d'avance.
--=20
Christophe PEREZ
--
gentoo-user-fr@gentoo.org mailing list
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Christophe PEREZ
Le Tue, 12 Jul 2005 02:59:43 -0400, Christophe PEREZ a écrit :
Je suis preneur de toute solution me permettant d'en virer l'un des 2, sans toutefois perdre l'usage de java dans une application.
Ben il semblerait en fait que de virer le jre, en faisant un env-update derrière, n'impose pas de le réinstaller au emerge -u world suivant.
J'en déduis que je me retrouve à chaque fois avec les 2 car j'install e toujours firefox avant openoffice, et firefox fait installer le jre alors qu'openoffice nécessiterait le jdk. Mais si le jdk est installé, le j re n'est pas requis.
-- Christophe PEREZ -- mailing list
Le Tue, 12 Jul 2005 02:59:43 -0400, Christophe PEREZ a écrit :
Je suis preneur de toute solution me permettant d'en virer l'un des 2,
sans toutefois perdre l'usage de java dans une application.
Ben il semblerait en fait que de virer le jre, en faisant un env-update
derrière, n'impose pas de le réinstaller au emerge -u world suivant.
J'en déduis que je me retrouve à chaque fois avec les 2 car j'install e
toujours firefox avant openoffice, et firefox fait installer le jre alors
qu'openoffice nécessiterait le jdk. Mais si le jdk est installé, le j re
n'est pas requis.
--
Christophe PEREZ
--
gentoo-user-fr@gentoo.org mailing list
Le Tue, 12 Jul 2005 02:59:43 -0400, Christophe PEREZ a écrit :
Je suis preneur de toute solution me permettant d'en virer l'un des 2, sans toutefois perdre l'usage de java dans une application.
Ben il semblerait en fait que de virer le jre, en faisant un env-update derrière, n'impose pas de le réinstaller au emerge -u world suivant.
J'en déduis que je me retrouve à chaque fois avec les 2 car j'install e toujours firefox avant openoffice, et firefox fait installer le jre alors qu'openoffice nécessiterait le jdk. Mais si le jdk est installé, le j re n'est pas requis.
-- Christophe PEREZ -- mailing list
Stéphan BERNARD
Christophe PEREZ wrote:
Le Tue, 12 Jul 2005 02:59:43 -0400, Christophe PEREZ a écrit : J'en déduis que je me retrouve à chaque fois avec les 2 car j'installe toujours firefox avant openoffice, et firefox fait installer le jre alors qu'openoffice nécessiterait le jdk. Mais si le jdk est installé, le jre n'est pas requis.
Il me semble qu'openoffice nécessite le jdk pour être compilé. Une fois compilé, le jre suffit.
En gros, le jre ne contient que la machine virtuelle nécessaire à l'exécution de programmes java, alors que le jdk contient en plus le nécessaire pour compiler des programmes java, + de la doc pour les développeurs + des démos, etc...
Un moyen d'être un peu plus léger pour la compilation consisterait à utliser jikes (petit et rapide) en complément du jre plutôt que le jdk, mais je ne sais pas dans quelle mesure des applications telles que openoffice arrivent à faire avec. Mais pour un liveCD, un openoffice-bin ne serait-il pas plus adapté ?
-- Stéphan BERNARD -- mailing list
Christophe PEREZ wrote:
Le Tue, 12 Jul 2005 02:59:43 -0400, Christophe PEREZ a écrit :
J'en déduis que je me retrouve à chaque fois avec les 2 car j'installe
toujours firefox avant openoffice, et firefox fait installer le jre alors
qu'openoffice nécessiterait le jdk. Mais si le jdk est installé, le jre
n'est pas requis.
Il me semble qu'openoffice nécessite le jdk pour être compilé. Une fois
compilé, le jre suffit.
En gros, le jre ne contient que la machine virtuelle nécessaire à
l'exécution de programmes java, alors que le jdk contient en plus le
nécessaire pour compiler des programmes java, + de la doc pour les
développeurs + des démos, etc...
Un moyen d'être un peu plus léger pour la compilation consisterait à
utliser jikes (petit et rapide) en complément du jre plutôt que le jdk,
mais je ne sais pas dans quelle mesure des applications telles que
openoffice arrivent à faire avec. Mais pour un liveCD, un openoffice-bin
ne serait-il pas plus adapté ?
--
Stéphan BERNARD
--
gentoo-user-fr@gentoo.org mailing list
Le Tue, 12 Jul 2005 02:59:43 -0400, Christophe PEREZ a écrit : J'en déduis que je me retrouve à chaque fois avec les 2 car j'installe toujours firefox avant openoffice, et firefox fait installer le jre alors qu'openoffice nécessiterait le jdk. Mais si le jdk est installé, le jre n'est pas requis.
Il me semble qu'openoffice nécessite le jdk pour être compilé. Une fois compilé, le jre suffit.
En gros, le jre ne contient que la machine virtuelle nécessaire à l'exécution de programmes java, alors que le jdk contient en plus le nécessaire pour compiler des programmes java, + de la doc pour les développeurs + des démos, etc...
Un moyen d'être un peu plus léger pour la compilation consisterait à utliser jikes (petit et rapide) en complément du jre plutôt que le jdk, mais je ne sais pas dans quelle mesure des applications telles que openoffice arrivent à faire avec. Mais pour un liveCD, un openoffice-bin ne serait-il pas plus adapté ?
-- Stéphan BERNARD -- mailing list
Christophe PEREZ
Le Tue, 12 Jul 2005 10:07:28 +0200, Stéphan BERNARD a écrit :
Il me semble qu'openoffice nécessite le jdk pour être compilé. Un e fois compilé, le jre suffit.
Je crois l'avoir effectivement compris.
En gros, le jre ne contient que la machine virtuelle nécessaire à l'exécution de programmes java, alors que le jdk contient en plus le nécessaire pour compiler des programmes java, + de la doc pour les développeurs + des démos, etc...
Oui oui, j'ai vu tout ça.
Un moyen d'être un peu plus léger pour la compilation consisterait à utliser jikes (petit et rapide) en complément du jre plutôt que le jdk, mais je ne sais pas dans quelle mesure des applications telles que openoffice arrivent à faire avec.
Ce n'est pas trop le problème, la compilation en elle même. Là, la fabrication du livecd, tous stages compris, doit bien prendre 2 jours. dont effectivement la moitié pour openoffice.
Mais pour un liveCD, un openoffice-bin ne serait-il pas plus adapté ?
Pourquoi plus adapté ? Que ma compilation me prenne 1 ou 2 jours n'est pas trop important pour moi. C'est juste au moment de tous mes tests de création du livecd que c'est pénalisant, mais comme de toutes les façons, catalyst permet de faire et utiliser les packages déjà compilés, j'aime encore autant avoir un vrai openoffice optimisé qu'une version binaire. Mon problème est principalement une question de taille de l'iso. En effet, dans le but de l'utiliser non seulement sur CD, mais surtout su r clé usb de façon à avoir un vrai système complet avec sauvegarde de mes données dessus, il me faut avoir une taille << 512Mo (taille de la clé immédiatement inférieure à un CD). Or, une clé usb de 512Mo, ça ne fait évidemment pas 512Mo, la mienn e faisant 494Mo. Il me faut aussi réserver 8.4Mo au noyau, et je veux pouvoir réserver un peu de place pour les données.
Hier, avec les 2 blackdowns, j'étais à une iso de 505Mo, pour un syst ème de 1642Mo comprenant les softs suivants , sans parler évidemment des dépendances (380 packages) et de tous les petits utilitaires (genre zip , pilotes wifi etc) : gedit vim cedega vmware-workstation screen grisbi openoffice gpdf kdewebdev evolution eog gimp gqview imagemagick cdparanoia grip teamspeak2-client-bin xmms mplayer realplayer nmap ppp rp-pppoe speedtouc h gftp gaim ntp openssh rsync wget liferea pan cups mplayerplug-in rox ivma n parted gpart mozilla-firefox synergy xbindkeys xfce4 xfce4-extras
Tout ça en Français, avec bien entendu un maximum de USE et de module s noyau.
Aujourd'hui, après suppression du blackdown-jdk, je tombe à # echo $(($(du -sk /sauve_loc/catalyst/tmp/default/livecd-stage2-pentium3-cp20050629/ | cut -f1)/1024))" Mo" 1555 Mo ce qui me donne une iso de : # ls -lh /sauve_loc/gentoo_cp20050629.iso -rw-r--r-- 1 root root 473M jui 12 05:51 /sauve_loc/gentoo_cp20050629.is o
On s'approche, mais je suis convaincu que je dois pouvoir virer plein de lib utiles seulement à la compilation, mais j'ai une liste longue comme le bras, et il me faudrait savoir pour chaque soft qui les utilise, s'il en a besoin au fonctionnement ou pas. Lourd !
-- Christophe PEREZ -- mailing list
Le Tue, 12 Jul 2005 10:07:28 +0200, Stéphan BERNARD a écrit :
Il me semble qu'openoffice nécessite le jdk pour être compilé. Un e fois
compilé, le jre suffit.
Je crois l'avoir effectivement compris.
En gros, le jre ne contient que la machine virtuelle nécessaire à
l'exécution de programmes java, alors que le jdk contient en plus le
nécessaire pour compiler des programmes java, + de la doc pour les
développeurs + des démos, etc...
Oui oui, j'ai vu tout ça.
Un moyen d'être un peu plus léger pour la compilation consisterait à
utliser jikes (petit et rapide) en complément du jre plutôt que le jdk,
mais je ne sais pas dans quelle mesure des applications telles que
openoffice arrivent à faire avec.
Ce n'est pas trop le problème, la compilation en elle même.
Là, la fabrication du livecd, tous stages compris, doit bien prendre 2
jours. dont effectivement la moitié pour openoffice.
Mais pour un liveCD, un openoffice-bin ne serait-il pas plus adapté ?
Pourquoi plus adapté ?
Que ma compilation me prenne 1 ou 2 jours n'est pas trop important pour
moi. C'est juste au moment de tous mes tests de création du livecd que
c'est pénalisant, mais comme de toutes les façons, catalyst permet de
faire et utiliser les packages déjà compilés, j'aime encore autant
avoir un vrai openoffice optimisé qu'une version binaire.
Mon problème est principalement une question de taille de l'iso.
En effet, dans le but de l'utiliser non seulement sur CD, mais surtout su r
clé usb de façon à avoir un vrai système complet avec sauvegarde de
mes données dessus, il me faut avoir une taille << 512Mo (taille de la
clé immédiatement inférieure à un CD).
Or, une clé usb de 512Mo, ça ne fait évidemment pas 512Mo, la mienn e
faisant 494Mo.
Il me faut aussi réserver 8.4Mo au noyau, et je veux pouvoir réserver un
peu de place pour les données.
Hier, avec les 2 blackdowns, j'étais à une iso de 505Mo, pour un syst ème
de 1642Mo comprenant les softs suivants , sans parler évidemment des
dépendances (380 packages) et de tous les petits utilitaires (genre zip ,
pilotes wifi etc) :
gedit vim cedega vmware-workstation screen grisbi openoffice gpdf
kdewebdev evolution eog gimp gqview imagemagick cdparanoia grip
teamspeak2-client-bin xmms mplayer realplayer nmap ppp rp-pppoe speedtouc h
gftp gaim ntp openssh rsync wget liferea pan cups mplayerplug-in rox ivma n
parted gpart mozilla-firefox synergy xbindkeys xfce4 xfce4-extras
Tout ça en Français, avec bien entendu un maximum de USE et de module s
noyau.
Aujourd'hui, après suppression du blackdown-jdk, je tombe à
# echo $(($(du -sk
/sauve_loc/catalyst/tmp/default/livecd-stage2-pentium3-cp20050629/ | cut
-f1)/1024))" Mo"
1555 Mo
ce qui me donne une iso de :
# ls -lh /sauve_loc/gentoo_cp20050629.iso
-rw-r--r-- 1 root root 473M jui 12 05:51 /sauve_loc/gentoo_cp20050629.is o
On s'approche, mais je suis convaincu que je dois pouvoir virer plein de
lib utiles seulement à la compilation, mais j'ai une liste longue comme
le bras, et il me faudrait savoir pour chaque soft qui les utilise, s'il
en a besoin au fonctionnement ou pas. Lourd !
--
Christophe PEREZ
--
gentoo-user-fr@gentoo.org mailing list
Le Tue, 12 Jul 2005 10:07:28 +0200, Stéphan BERNARD a écrit :
Il me semble qu'openoffice nécessite le jdk pour être compilé. Un e fois compilé, le jre suffit.
Je crois l'avoir effectivement compris.
En gros, le jre ne contient que la machine virtuelle nécessaire à l'exécution de programmes java, alors que le jdk contient en plus le nécessaire pour compiler des programmes java, + de la doc pour les développeurs + des démos, etc...
Oui oui, j'ai vu tout ça.
Un moyen d'être un peu plus léger pour la compilation consisterait à utliser jikes (petit et rapide) en complément du jre plutôt que le jdk, mais je ne sais pas dans quelle mesure des applications telles que openoffice arrivent à faire avec.
Ce n'est pas trop le problème, la compilation en elle même. Là, la fabrication du livecd, tous stages compris, doit bien prendre 2 jours. dont effectivement la moitié pour openoffice.
Mais pour un liveCD, un openoffice-bin ne serait-il pas plus adapté ?
Pourquoi plus adapté ? Que ma compilation me prenne 1 ou 2 jours n'est pas trop important pour moi. C'est juste au moment de tous mes tests de création du livecd que c'est pénalisant, mais comme de toutes les façons, catalyst permet de faire et utiliser les packages déjà compilés, j'aime encore autant avoir un vrai openoffice optimisé qu'une version binaire. Mon problème est principalement une question de taille de l'iso. En effet, dans le but de l'utiliser non seulement sur CD, mais surtout su r clé usb de façon à avoir un vrai système complet avec sauvegarde de mes données dessus, il me faut avoir une taille << 512Mo (taille de la clé immédiatement inférieure à un CD). Or, une clé usb de 512Mo, ça ne fait évidemment pas 512Mo, la mienn e faisant 494Mo. Il me faut aussi réserver 8.4Mo au noyau, et je veux pouvoir réserver un peu de place pour les données.
Hier, avec les 2 blackdowns, j'étais à une iso de 505Mo, pour un syst ème de 1642Mo comprenant les softs suivants , sans parler évidemment des dépendances (380 packages) et de tous les petits utilitaires (genre zip , pilotes wifi etc) : gedit vim cedega vmware-workstation screen grisbi openoffice gpdf kdewebdev evolution eog gimp gqview imagemagick cdparanoia grip teamspeak2-client-bin xmms mplayer realplayer nmap ppp rp-pppoe speedtouc h gftp gaim ntp openssh rsync wget liferea pan cups mplayerplug-in rox ivma n parted gpart mozilla-firefox synergy xbindkeys xfce4 xfce4-extras
Tout ça en Français, avec bien entendu un maximum de USE et de module s noyau.
Aujourd'hui, après suppression du blackdown-jdk, je tombe à # echo $(($(du -sk /sauve_loc/catalyst/tmp/default/livecd-stage2-pentium3-cp20050629/ | cut -f1)/1024))" Mo" 1555 Mo ce qui me donne une iso de : # ls -lh /sauve_loc/gentoo_cp20050629.iso -rw-r--r-- 1 root root 473M jui 12 05:51 /sauve_loc/gentoo_cp20050629.is o
On s'approche, mais je suis convaincu que je dois pouvoir virer plein de lib utiles seulement à la compilation, mais j'ai une liste longue comme le bras, et il me faudrait savoir pour chaque soft qui les utilise, s'il en a besoin au fonctionnement ou pas. Lourd !
