déja si vielle ma 9.1?
Debian je n'arrive pas à booter
dessus sauf en kernel 2.2 :-( )
Si je prends un rpm récent de gcompris (sur le site officiel), j'ai des
problèmes de dépendances.
général des "dépendances", et le fait que ce qu'a fait l'équipe de mozdev
avec FireFox est vraiment EXCELLENT!
mais les auteurs de softs devraient
penser qu'on a pas "tous" la même distro avec les mêmes deps.
déja si vielle ma 9.1?
Debian je n'arrive pas à booter
dessus sauf en kernel 2.2 :-( )
Si je prends un rpm récent de gcompris (sur le site officiel), j'ai des
problèmes de dépendances.
général des "dépendances", et le fait que ce qu'a fait l'équipe de mozdev
avec FireFox est vraiment EXCELLENT!
mais les auteurs de softs devraient
penser qu'on a pas "tous" la même distro avec les mêmes deps.
déja si vielle ma 9.1?
Debian je n'arrive pas à booter
dessus sauf en kernel 2.2 :-( )
Si je prends un rpm récent de gcompris (sur le site officiel), j'ai des
problèmes de dépendances.
général des "dépendances", et le fait que ce qu'a fait l'équipe de mozdev
avec FireFox est vraiment EXCELLENT!
mais les auteurs de softs devraient
penser qu'on a pas "tous" la même distro avec les mêmes deps.
Gcompris sur le site officiel
Site officiel,
gEDA n'est pas dans ma distro, et celui pour mdk de rpmfind
marche pas mieux.
Je ne sais déja pas en français la différence entre une librairie ou une
bibliothèque, et j'utilise qu'un seul mot pour les 2! bref, on y touve des
bouquins moi, je dit libliothèque, comme ça y'a pas d'erreurs ;-)
Gcompris sur le site officiel
Site officiel,
gEDA n'est pas dans ma distro, et celui pour mdk de rpmfind
marche pas mieux.
Je ne sais déja pas en français la différence entre une librairie ou une
bibliothèque, et j'utilise qu'un seul mot pour les 2! bref, on y touve des
bouquins moi, je dit libliothèque, comme ça y'a pas d'erreurs ;-)
Gcompris sur le site officiel
Site officiel,
gEDA n'est pas dans ma distro, et celui pour mdk de rpmfind
marche pas mieux.
Je ne sais déja pas en français la différence entre une librairie ou une
bibliothèque, et j'utilise qu'un seul mot pour les 2! bref, on y touve des
bouquins moi, je dit libliothèque, comme ça y'a pas d'erreurs ;-)
En tout cas, le bonheur sous linux serait de trouver plus de softs comme
FireFox, car les rpm... quand tout marche c'est génial, mais sinon ça chie
dans la colle, et y'a pas de juste milieu. Ça fonctionne à merveille ou ça
chie dans la colle sans intermédiare. Même emerge (gentoo) a des
dépendances chiantes...
AHAM, les auteurs devraient proposer une version "précompilée" toute
complette à la "FireFox" pour les nioubs,ainsi que pour ceux ne voulant pas
installer plein de libs pour n' utiliser qu'un *.so de chaque libs pour un
seul soft, soit 1Go de dépendances pour un soft de 100K (bon, j'exagère,
mais vous saisissez l'image ;-) )
En tout cas, le bonheur sous linux serait de trouver plus de softs comme
FireFox, car les rpm... quand tout marche c'est génial, mais sinon ça chie
dans la colle, et y'a pas de juste milieu. Ça fonctionne à merveille ou ça
chie dans la colle sans intermédiare. Même emerge (gentoo) a des
dépendances chiantes...
AHAM, les auteurs devraient proposer une version "précompilée" toute
complette à la "FireFox" pour les nioubs,ainsi que pour ceux ne voulant pas
installer plein de libs pour n' utiliser qu'un *.so de chaque libs pour un
seul soft, soit 1Go de dépendances pour un soft de 100K (bon, j'exagère,
mais vous saisissez l'image ;-) )
En tout cas, le bonheur sous linux serait de trouver plus de softs comme
FireFox, car les rpm... quand tout marche c'est génial, mais sinon ça chie
dans la colle, et y'a pas de juste milieu. Ça fonctionne à merveille ou ça
chie dans la colle sans intermédiare. Même emerge (gentoo) a des
dépendances chiantes...
AHAM, les auteurs devraient proposer une version "précompilée" toute
complette à la "FireFox" pour les nioubs,ainsi que pour ceux ne voulant pas
installer plein de libs pour n' utiliser qu'un *.so de chaque libs pour un
seul soft, soit 1Go de dépendances pour un soft de 100K (bon, j'exagère,
mais vous saisissez l'image ;-) )
Web Dreamer , dans le message <40c8a8e5$0$19423$,Gcompris sur le site officiel
On va y arriver : il était fourni pour quelle distribution exactement,
ce RPM ?Site officiel,
Idem.gEDA n'est pas dans ma distro, et celui pour mdk de rpmfind
marche pas mieux.
Pour information, si c'est bien « GNU Electronics design software » que
tu évoques, c'est disponible chez Debian.
<rant>
Plus ça va, et plus je me dis que le mode de fonctionnement des
distributions avec des releases tous les six mois ou un an est mauvais
pour une utilisation personnelle (poste de travail ou maison, par
opposition à un austère serveur), et qu'il vaut mieux une mise à jour
progressive qui assure autant que possible la compatibilité.
</rant>
Web Dreamer , dans le message <40c8a8e5$0$19423$626a14ce@news.free.fr>,
Gcompris sur le site officiel
On va y arriver : il était fourni pour quelle distribution exactement,
ce RPM ?
Site officiel,
Idem.
gEDA n'est pas dans ma distro, et celui pour mdk de rpmfind
marche pas mieux.
Pour information, si c'est bien « GNU Electronics design software » que
tu évoques, c'est disponible chez Debian.
<rant>
Plus ça va, et plus je me dis que le mode de fonctionnement des
distributions avec des releases tous les six mois ou un an est mauvais
pour une utilisation personnelle (poste de travail ou maison, par
opposition à un austère serveur), et qu'il vaut mieux une mise à jour
progressive qui assure autant que possible la compatibilité.
</rant>
Web Dreamer , dans le message <40c8a8e5$0$19423$,Gcompris sur le site officiel
On va y arriver : il était fourni pour quelle distribution exactement,
ce RPM ?Site officiel,
Idem.gEDA n'est pas dans ma distro, et celui pour mdk de rpmfind
marche pas mieux.
Pour information, si c'est bien « GNU Electronics design software » que
tu évoques, c'est disponible chez Debian.
<rant>
Plus ça va, et plus je me dis que le mode de fonctionnement des
distributions avec des releases tous les six mois ou un an est mauvais
pour une utilisation personnelle (poste de travail ou maison, par
opposition à un austère serveur), et qu'il vaut mieux une mise à jour
progressive qui assure autant que possible la compatibilité.
</rant>
En fait, le problème de Linux à ce niveau vient de la multiplicité des
distributions, ce qui fait chaque programme doit être empaqueté
spécifiquement pour chaque distribution.
Ainsi, un Fedora 2 et une Mandrake 10, pourtant sorties +/- en même
temps, ne proposent pas les mêmes versions des libs ni des softs.
A charge alors du gestionnaire de paquetages "évolué" (apt, yum, urpmi,
etc.) de satisfaire les dépendances nécessaires, dans la mesure du
possible (dépendances circulaires ou contradictoires, comme exposées
dans le post initial).
A l'inverse, un programme développé pour un OS "unique" sait quelle
version de cet OS contient les libs nécessaires, et on a donc des
programmes pour Windows 98, MacOS 10.2.3, FreeBSD 4.3, etc.
Dans ce cas, c'est le programmeur qui doit faire attention à ce qu'il
utilise, afin que son programme puisse tourner correctement.
<Troll>
C'est le genre d'arguments qui donne du grain à moudre à ceux qui
prédisent que Linux mourra comme Unix, et pour la même cause: la
fragmentation.
Rendez-vous dans 10 ans? ;-)
</Troll>
En fait, le problème de Linux à ce niveau vient de la multiplicité des
distributions, ce qui fait chaque programme doit être empaqueté
spécifiquement pour chaque distribution.
Ainsi, un Fedora 2 et une Mandrake 10, pourtant sorties +/- en même
temps, ne proposent pas les mêmes versions des libs ni des softs.
A charge alors du gestionnaire de paquetages "évolué" (apt, yum, urpmi,
etc.) de satisfaire les dépendances nécessaires, dans la mesure du
possible (dépendances circulaires ou contradictoires, comme exposées
dans le post initial).
A l'inverse, un programme développé pour un OS "unique" sait quelle
version de cet OS contient les libs nécessaires, et on a donc des
programmes pour Windows 98, MacOS 10.2.3, FreeBSD 4.3, etc.
Dans ce cas, c'est le programmeur qui doit faire attention à ce qu'il
utilise, afin que son programme puisse tourner correctement.
<Troll>
C'est le genre d'arguments qui donne du grain à moudre à ceux qui
prédisent que Linux mourra comme Unix, et pour la même cause: la
fragmentation.
Rendez-vous dans 10 ans? ;-)
</Troll>
En fait, le problème de Linux à ce niveau vient de la multiplicité des
distributions, ce qui fait chaque programme doit être empaqueté
spécifiquement pour chaque distribution.
Ainsi, un Fedora 2 et une Mandrake 10, pourtant sorties +/- en même
temps, ne proposent pas les mêmes versions des libs ni des softs.
A charge alors du gestionnaire de paquetages "évolué" (apt, yum, urpmi,
etc.) de satisfaire les dépendances nécessaires, dans la mesure du
possible (dépendances circulaires ou contradictoires, comme exposées
dans le post initial).
A l'inverse, un programme développé pour un OS "unique" sait quelle
version de cet OS contient les libs nécessaires, et on a donc des
programmes pour Windows 98, MacOS 10.2.3, FreeBSD 4.3, etc.
Dans ce cas, c'est le programmeur qui doit faire attention à ce qu'il
utilise, afin que son programme puisse tourner correctement.
<Troll>
C'est le genre d'arguments qui donne du grain à moudre à ceux qui
prédisent que Linux mourra comme Unix, et pour la même cause: la
fragmentation.
Rendez-vous dans 10 ans? ;-)
</Troll>
Jerome Lambert () à écrit le Jeudi 10 Juin
2004 22:20 dans sur
fr.comp.os.linux.debats:En fait, le problème de Linux à ce niveau vient de la multiplicité des
distributions, ce qui fait chaque programme doit être empaqueté
spécifiquement pour chaque distribution.
Ainsi, un Fedora 2 et une Mandrake 10, pourtant sorties +/- en même
temps, ne proposent pas les mêmes versions des libs ni des softs.
A charge alors du gestionnaire de paquetages "évolué" (apt, yum, urpmi,
etc.) de satisfaire les dépendances nécessaires, dans la mesure du
possible (dépendances circulaires ou contradictoires, comme exposées
dans le post initial).
La force de l'équipe de mozilla est que FireFox fonctionne sur toutes les
distris, sans faire d'efforts pour l'utilisateur.
AHMA, un éditeur de softs linux devrait éditer son soft pour "toutes distro"
à la façons FireFox, et ensuite, les éditeurs de distros peuvent si ils le
veulent créer de packqetages propres à leur distro. Si les softs GPL
étaient réalisés ainsi, Linux progresserait ahma beaucoup plus vite. car on
n'aurait aucuns problèmes d'installation.
Seule dépendance : au "distrowide" : un kernel Linux (toutes versions), et
éventuellement Xfree, gtk et/ou qt si c'est un soft en GUI.
glibc est il assez standard pour être en "distrowide" avec gcc? Si oui,
c'est pas un problème non plus. mais tout le reste (qui n'est pas identique
à chaque distri) devrait être inclus dans le soft.
Je rêve peut être? ;-)
Jerome Lambert (jerome.lambert@swing.aretirer.be) à écrit le Jeudi 10 Juin
2004 22:20 dans <pan.2004.06.10.20.20.27.994011@swing.aretirer.be> sur
fr.comp.os.linux.debats:
En fait, le problème de Linux à ce niveau vient de la multiplicité des
distributions, ce qui fait chaque programme doit être empaqueté
spécifiquement pour chaque distribution.
Ainsi, un Fedora 2 et une Mandrake 10, pourtant sorties +/- en même
temps, ne proposent pas les mêmes versions des libs ni des softs.
A charge alors du gestionnaire de paquetages "évolué" (apt, yum, urpmi,
etc.) de satisfaire les dépendances nécessaires, dans la mesure du
possible (dépendances circulaires ou contradictoires, comme exposées
dans le post initial).
La force de l'équipe de mozilla est que FireFox fonctionne sur toutes les
distris, sans faire d'efforts pour l'utilisateur.
AHMA, un éditeur de softs linux devrait éditer son soft pour "toutes distro"
à la façons FireFox, et ensuite, les éditeurs de distros peuvent si ils le
veulent créer de packqetages propres à leur distro. Si les softs GPL
étaient réalisés ainsi, Linux progresserait ahma beaucoup plus vite. car on
n'aurait aucuns problèmes d'installation.
Seule dépendance : au "distrowide" : un kernel Linux (toutes versions), et
éventuellement Xfree, gtk et/ou qt si c'est un soft en GUI.
glibc est il assez standard pour être en "distrowide" avec gcc? Si oui,
c'est pas un problème non plus. mais tout le reste (qui n'est pas identique
à chaque distri) devrait être inclus dans le soft.
Je rêve peut être? ;-)
Jerome Lambert () à écrit le Jeudi 10 Juin
2004 22:20 dans sur
fr.comp.os.linux.debats:En fait, le problème de Linux à ce niveau vient de la multiplicité des
distributions, ce qui fait chaque programme doit être empaqueté
spécifiquement pour chaque distribution.
Ainsi, un Fedora 2 et une Mandrake 10, pourtant sorties +/- en même
temps, ne proposent pas les mêmes versions des libs ni des softs.
A charge alors du gestionnaire de paquetages "évolué" (apt, yum, urpmi,
etc.) de satisfaire les dépendances nécessaires, dans la mesure du
possible (dépendances circulaires ou contradictoires, comme exposées
dans le post initial).
La force de l'équipe de mozilla est que FireFox fonctionne sur toutes les
distris, sans faire d'efforts pour l'utilisateur.
AHMA, un éditeur de softs linux devrait éditer son soft pour "toutes distro"
à la façons FireFox, et ensuite, les éditeurs de distros peuvent si ils le
veulent créer de packqetages propres à leur distro. Si les softs GPL
étaient réalisés ainsi, Linux progresserait ahma beaucoup plus vite. car on
n'aurait aucuns problèmes d'installation.
Seule dépendance : au "distrowide" : un kernel Linux (toutes versions), et
éventuellement Xfree, gtk et/ou qt si c'est un soft en GUI.
glibc est il assez standard pour être en "distrowide" avec gcc? Si oui,
c'est pas un problème non plus. mais tout le reste (qui n'est pas identique
à chaque distri) devrait être inclus dans le soft.
Je rêve peut être? ;-)
La force de l'équipe de mozilla est que FireFox fonctionne sur toutes les
distris, sans faire d'efforts pour l'utilisateur.
dans l'exemple de gEDA. ils n'auraient pas pu bêtement inclure dans leurs
sources le source de "libguile-ltdl.so.1" au lieux de demander une
dépendance chiante?
cela aurait été compliqué?
Il faut une lib complette pour un bête élément. soit un encombrement du
disque avec toute une lib (bibliotheque ;-) ) pour un seul élément qui sera
utilisé par leur soft!
Je rêve peut être? ;-)
La force de l'équipe de mozilla est que FireFox fonctionne sur toutes les
distris, sans faire d'efforts pour l'utilisateur.
dans l'exemple de gEDA. ils n'auraient pas pu bêtement inclure dans leurs
sources le source de "libguile-ltdl.so.1" au lieux de demander une
dépendance chiante?
cela aurait été compliqué?
Il faut une lib complette pour un bête élément. soit un encombrement du
disque avec toute une lib (bibliotheque ;-) ) pour un seul élément qui sera
utilisé par leur soft!
Je rêve peut être? ;-)
La force de l'équipe de mozilla est que FireFox fonctionne sur toutes les
distris, sans faire d'efforts pour l'utilisateur.
dans l'exemple de gEDA. ils n'auraient pas pu bêtement inclure dans leurs
sources le source de "libguile-ltdl.so.1" au lieux de demander une
dépendance chiante?
cela aurait été compliqué?
Il faut une lib complette pour un bête élément. soit un encombrement du
disque avec toute une lib (bibliotheque ;-) ) pour un seul élément qui sera
utilisé par leur soft!
Je rêve peut être? ;-)
A l'inverse, un programme développé pour un OS "unique" sait quelle
version de cet OS contient les libs nécessaires, et on a donc des
programmes pour Windows 98, MacOS 10.2.3, FreeBSD 4.3, etc.
^^^^^^^^^^
A l'inverse, un programme développé pour un OS "unique" sait quelle
version de cet OS contient les libs nécessaires, et on a donc des
programmes pour Windows 98, MacOS 10.2.3, FreeBSD 4.3, etc.
^^^^^^^^^^
A l'inverse, un programme développé pour un OS "unique" sait quelle
version de cet OS contient les libs nécessaires, et on a donc des
programmes pour Windows 98, MacOS 10.2.3, FreeBSD 4.3, etc.
^^^^^^^^^^
Comme je l'ai dit plus haut, Mozilla a pour lui faciliter la vie le fait
qu'il n'utilise que très très peu de code externe. De plus, la version
distribuée que tu vantes tant est très largement diminuée par rapport à
ce qu'on peut avoir en installant une version faite spécifiquement pour
une distribution moderne (je parle en connaissance de cause, j'ai
compilé un Firefox il y a moins de dix heures, avec deux petits patches
maison sympa).
dans l'exemple de gEDA. ils n'auraient pas pu bêtement inclure dans leurs
sources le source de "libguile-ltdl.so.1" au lieux de demander une
dépendance chiante?
cela aurait été compliqué?
Il faut une lib complette pour un bête élément. soit un encombrement du
disque avec toute une lib (bibliotheque ;-) ) pour un seul élément qui
sera utilisé par leur soft!
T'es-tu dit que peut-être libguile-ltdl.so.1 risquait d'avoir lui-même
besoin d'autres .so, qui eux-mêmes auraient besoin d'autres .so, etc. ?Je rêve peut être? ;-)
Plutôt un cauchemar : 80 Mo à télécharger tout Gnome ou KDE pour la
moindre petite application de 2 Mo, alors qu'on aurait déjà quatre ou
cinq exemplaires des bibliothèques nécessaires sur son disque dur,
quelle horreur.
Comme je l'ai dit plus haut, Mozilla a pour lui faciliter la vie le fait
qu'il n'utilise que très très peu de code externe. De plus, la version
distribuée que tu vantes tant est très largement diminuée par rapport à
ce qu'on peut avoir en installant une version faite spécifiquement pour
une distribution moderne (je parle en connaissance de cause, j'ai
compilé un Firefox il y a moins de dix heures, avec deux petits patches
maison sympa).
dans l'exemple de gEDA. ils n'auraient pas pu bêtement inclure dans leurs
sources le source de "libguile-ltdl.so.1" au lieux de demander une
dépendance chiante?
cela aurait été compliqué?
Il faut une lib complette pour un bête élément. soit un encombrement du
disque avec toute une lib (bibliotheque ;-) ) pour un seul élément qui
sera utilisé par leur soft!
T'es-tu dit que peut-être libguile-ltdl.so.1 risquait d'avoir lui-même
besoin d'autres .so, qui eux-mêmes auraient besoin d'autres .so, etc. ?
Je rêve peut être? ;-)
Plutôt un cauchemar : 80 Mo à télécharger tout Gnome ou KDE pour la
moindre petite application de 2 Mo, alors qu'on aurait déjà quatre ou
cinq exemplaires des bibliothèques nécessaires sur son disque dur,
quelle horreur.
Comme je l'ai dit plus haut, Mozilla a pour lui faciliter la vie le fait
qu'il n'utilise que très très peu de code externe. De plus, la version
distribuée que tu vantes tant est très largement diminuée par rapport à
ce qu'on peut avoir en installant une version faite spécifiquement pour
une distribution moderne (je parle en connaissance de cause, j'ai
compilé un Firefox il y a moins de dix heures, avec deux petits patches
maison sympa).
dans l'exemple de gEDA. ils n'auraient pas pu bêtement inclure dans leurs
sources le source de "libguile-ltdl.so.1" au lieux de demander une
dépendance chiante?
cela aurait été compliqué?
Il faut une lib complette pour un bête élément. soit un encombrement du
disque avec toute une lib (bibliotheque ;-) ) pour un seul élément qui
sera utilisé par leur soft!
T'es-tu dit que peut-être libguile-ltdl.so.1 risquait d'avoir lui-même
besoin d'autres .so, qui eux-mêmes auraient besoin d'autres .so, etc. ?Je rêve peut être? ;-)
Plutôt un cauchemar : 80 Mo à télécharger tout Gnome ou KDE pour la
moindre petite application de 2 Mo, alors qu'on aurait déjà quatre ou
cinq exemplaires des bibliothèques nécessaires sur son disque dur,
quelle horreur.
C'est à cause de la clause copyleft. Tu ne peux pas
copier sur le même disque une oeuvre dérivée de numéros
de version strictement suppérieur sans que les sources
soient NON patchés.
C'est interdit.
J'ai pas tout compris, là...
C'est à cause de la clause copyleft. Tu ne peux pas
copier sur le même disque une oeuvre dérivée de numéros
de version strictement suppérieur sans que les sources
soient NON patchés.
C'est interdit.
J'ai pas tout compris, là...
C'est à cause de la clause copyleft. Tu ne peux pas
copier sur le même disque une oeuvre dérivée de numéros
de version strictement suppérieur sans que les sources
soient NON patchés.
C'est interdit.
J'ai pas tout compris, là...