Petits progrès à faire.

nicolas vigier s'est exprimé en ces termes:

Comment avec aussi peu de details peux tu etre sur que le probleme vient de
Mandrake ?

Parce que nulle part dans son post il n'a dit qu'il utilisait des
packages non-officiels ?

Si j'installe des .deb qui viennent de n'importe ou sur ma debian, je peut
aussi avoir quelques problemes de ce genre ...

Le fait est que c'est le merdier avec des packages officiels. Il est
devenu interdit de faire remarquer que le format RPM était toujours
aussi pourri, ici ?


--
<NtG> people beta test a MS product every time they boot windows

<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>

Ben plus ça va, plus je me dit la même chose et suis entièrement d'accord.
Je ne comprends pas pourquoi on fait une "release" tous les 6 mois, et
c'est je l'avoue "gonflant". Je préfères "metre à jour" sans réinstaller
tous les 6 mois, et les éditeurs comme mandrake devrait s'en inspirer.

je crois que ce sont des societes commerciales qui vivent aussi de la vente

de leur cd ... donc faire de releases majeurs de toute la distrib leur
permet de faire un nouveau CD ... Surtout qu'une grande partie de leur
clientelle provient du monde windows, a l'affut de la nouveaute paske c'est
mieux, vu que c'est nouveau ...
Par exemple, mon serveur principal a tres longtemps tourne en MDK 7.2 ...
puis pour plein de raisons a basculé en 9.0 matiné de 9.1 (pas de 9.2 a
cause de la libc) avec juste les MAJ de securites ... Par contre les poste
de travail sont en MDK 9.2/10 pour des raisons de confort : c'est fou le
nombre de truc nouveau qu'il faut "supporter" pour que l'usager standart
soit "satisfait".

Jerome Lambert wrote:

Le Thu, 10 Jun 2004 16:46:16 +0200, Web Dreamer a écrit :

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

(snip)

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

d'un autre cote un usager averti, peut etre capable de savoir si la lib
deja installee sera compatible malgre un numero de version different afin
de forcer l'install (rpm --nodeps) ... surtout que si ça ne remplace rien
de present (rpm -qp --list) un rpm -e te l'enlevera sans soucis si ça ne
marche pas. autrement on peut aussi jouer avec le repertoire cible /lib
--> /usr/local/lib et le LDLIBRARY_PATH pour faire cohabiter des programmes
aux lib incompatibles ...

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

Certes mais pour le confort de tous, il suffit de faire une disrib
integralement compilee en statique ... ca regle le probleme des libs ...

Ce serait marrant que quelqu'un essaye ca ! je parle pas de l'occupation
memoire, avec des PC de 1GO de ram et 2 GO de swapcela devrait n'etre
quaccessoire !

Web Dreamer , dans le message <40c8e2bf$0$13827$626a14ce@news.free.fr>,
a écrit :

Ben moi c'est le contraire : sur ma mdk 9.1 fourni avec mozilla 1.3.1, la
version officielle (et pas mandrake) fonctionne vachement mieux, plus vite,
et sans bugs.
avec la version mandrake, les plugins flash tournaient au raalleennttii. et
avec la version officiel de mozilla c'est nickel!

Tu compares un Mozilla Mandrake « officiel » vieux avec le Firefox de
chez mozilla.org qui est tout récent : évidemment le dernier est mieux.
Moi je te parle des deux versions de la même génération, l'une packagée
génériquement selon tes goûts par mozilla.org, l'autre packagée par
Debian ou compilée par mes soins : la version de mozilla.org est
nulle : Gtk 1.2, pas de XFT, pas de SVG, plus longue à charger.

Non, comme j'ai dit plus haut, gnome et kde étant standards, ils feraient
parti des dépendances.
enfin, plutôt gtk et qt.

La, tu montres surtout que tu ne maîtrises pas assez les aspects
techniques pour te rendre compte de la faisabilité de ce que tu
proposes. Quelque grain à moudre :

- Gtk+ existe en deux versions : 1.2 et 2, qui sont des bibliothèques
différentes, non compatibles (ni dans un sens, ni dans l'autre) ; Gtk+
1.2 n'est plus développé, et n'a pas bougé de la version 1.2.10 depuis
plus de deux ans, et aucune 1.2 n'apportant de nouvelle fonctionnalité
par rapport à la précédente, uniquement des bugfix ; à l'inverse, Gtk+
2 est activement développée (on a eu la 2.0, la 2.2, la 2.4 est sortie
récemment), chaque nouvelle version mineure apporte de nouvelles
fonctionnalités, tout en gardant la compatibilité (source, et parfois
binaire) avec la version précédente.

Pour information, le Firefox de mozilla.org utilise Gtk+ 1.2.

- Qt est plus ou moins dans le même cas que Gtk+ 2 ; je ne connais pas
les détails des versions, mais il y a de nouvelles versions
régulièrement, et chacune apporte de nouvelles fonctionnalités.

- KDE et Gnome ne sont pas simplement un bureau et des applications
construits avec respectivement Qt et Gtk+, ce sont avant tout des
bibliothèques qui étendent les fonctionnalités de Qt et Gtk+ en
fournissant des fonctionnalités de bureau (communication
inter-application avec Gorba ou je ne sais quoi chez KDE), gestion
centralisée d'une configuration, bibliothèque d'icônes thèmables, etc.

- Des bibliothèques de ce genre sont souvent fortement
interdépendantes : un programme qui semble n'utiliser qu'un seul .so
va en fait nécessiter une grande partie de la bibliothèque à cause du
jeu de dépendances internes, éventuellement via du chargement
dynamique.

Maintenant, examinons les implications de ce que tu proposes :

- Si tu considères Gtk+ 2, Qt, KDE, Gnome comme des bibliothèques
annexes, les programmes doivent les inclure, et tu multiplies ainsi
par dix ou vingt la taille de chaque programme à télécharger.

- Si tu considères ces bibliothèques comme des composants essentiels du
système, tu exiges qu'ils soient figés dans une vieille version pour
assurer la compatibilité. Ce n'est pas acceptable.

D'une manière générale, il y a un point dont on ne sort pas, et je
l'avais d'ailleurs déjà énoncé la dernière fois que cette discussion
était sortie, je ne sais plus si c'est avec toi :

Su un programme a besoin pour marcher d'une bibliothèque (disons Gnome)
en version assez récente, alors il _faut_ d'une manière ou d'une autre
installer cette bibliothèque. On n'en sort pas. Inclure les
bibliothèques dans les programmes n'est pas une solution dès lors qu'il
s'agit de grosses bibliothèques. Dans ces conditions, le gestionnaire de
paquets de la distribution est normalement la solution la plus efficace
ET la plus simple.

et re-comme je le disait, c'est celui qui maintient la distro qui devrait
proposer une version moins lourde avec les dépendances supplémentaires déja
gérées.

Et moi je vais plus loin : l'auteur du programme ferait mieux de se
contenter de fournir les sources, et de s'abstenir de fournir des
binaires. D'ailleurs, pourquoi fourniraient-il des binaires pour
Linux/i386 et pas pour NetBSD/Sparc ?

chaqun 1% de chaque lib

Cette estimation n'est pas réaliste.

Soit 28M pour un soft qui n'utilise surement pas tout.

À part le fait que tu as en double l'anglais et le français, je pense au
contraire qu'il utilise tout. Quant au problème d'anglais/français, je
ne sais pas ce que fait la Mandrake, mais dans le cas de la Debian,
Gcompris dépend de gcompris-sound, paquet virtuel fourni au choix par la
version française ou anglaise. Bref, le résultat est optimal.

Pourquoi les autres softs refusent'ils libpython2 ?
Ou en est la rétrocompatibilité?

Il y a deux possibilités : soit il y a effectivement une incompatibilité
grave entre ces deux bibliothèques, soit la Mandrake a complètement
louzé ses dépendances. Dans le premier cas, il n'y a pas de solution
autre que mettre à jour tout ce qui en dépend. Dans le second cas, eh
bien manvaise distrib, changer de distrib.

Pourquoi autant de paquetages pour un seul soft?

Parce que c'est un logiciel qui réutilise du code déjà fait, ce qui lui
permet d'aller plus vite plus loin.

mais guile (756Ko sur mandrake) pour n'utiliser que libguile-ltdl.so.1, je
trouve ça du foutage de gueule, un simple libguile-ltdl.so.1 pourait être
intégré, gEDA est le *seul* soft sur mon disque de 10Go ras la gueule à
avoir besoin de libguile-ltdl.so.1 alors pourquoi une lib guile complête?

Pour le coup, Mandrake est prise en flagrand-délit de ne pas découper
assez :

Package: libguile-ltdl-1
Priority: optional
Section: libs
Installed-Size: 46

Mais bon, Guile est une bibliothèque pas mal utilisée et pas très
grosse, ça reste raisonnable.

C'est quand même con de booter sous windows 98 pour utiliser gEDA qui est
porté sous windows alors que c'est un soft Linux, et sous windows il s'en
fout de ces libs, et je n'ai que 3Go sous windows, bourré de softs GPL
(Open Office, Gimp, Dev C++, gEDA, etc, etc, etc...! Donc on peut le faire
non?

Mais scrogneugneu, mets à jour ta distrib, puisqu'elle est trop vieille.
Ou bien installe les programmes à partir des sources.

libguile-ltdl.so.1 pour gEDA ça doit pas prendre de place, donc là le mettre
en dépendance c'est ahma completement débile. (c'est un exemple)

Je vois ça autrement : la distribution pour laquelle est fourni le
binaire de gEDA dont tu parles fournit un package avec ce
libguile-ltdl.so.1, ce serait débile d'en fournir à nouveau un, ça
ferait double emploi et risquerait de causer des conflits.

Il faut que je vire : gnome games, gnumeric, gwrap, gnucash, glame pour
sattisfaire les dépendances et upgrader guile pour seulement
libguile-ltdl.so.1 qui doit être présent pour gEDA, et pour moi, c'est ça
le cauchemard.

(Cauchemar, sans d.) Non, il ne faut pas que tu les vires. Au pire, il
faut que tu les mettes à jour parce que ta distribution ne fait pas
forcément très bien les choses.

Sinon, je prédit à linux le même destin qu'unix, pour
cause de fragmentation. ;-)

Mais non. Tout va bien au contraire. C'est la fragmentation
(entres autre) qui a permis à cette dauberie d'unix de
survivre aussi longtemps.

--
I first wrote it in PL/I, then started over in assembler language
when the PL/I program was too big to fit in the computer.
--Richard Stallman

In article <slrncchvme.qh8.kwyxz@grumpf.kwyxz.org>, Benjamin FRANCOIS wrote:

nicolas vigier s'est exprimé en ces termes:

Comment avec aussi peu de details peux tu etre sur que le probleme vient de
Mandrake ?

Parce que nulle part dans son post il n'a dit qu'il utilisait des
packages non-officiels ?

Il ne l'a pas dit, mais c'est ce qu'il a fait.

Si j'installe des .deb qui viennent de n'importe ou sur ma debian, je peut
aussi avoir quelques problemes de ce genre ...

Le fait est que c'est le merdier avec des packages officiels. Il est
devenu interdit de faire remarquer que le format RPM était toujours
aussi pourri, ici ?

Non, ca n'etait pas des packages officiels. Et qu'y a il de si pourri dans
le format RPM, tu peux donner un peu plus de details ?

nicolas vigier s'est exprimé en ces termes:

Non, ca n'etait pas des packages officiels. Et qu'y a il de si pourri dans
le format RPM, tu peux donner un peu plus de details ?

Il lui manque une gestion des "suggest" ou des "recommend" par exemple.
Et une gestion de dépendances sur un package A _ou_ un package B.


--
<polaris> haha... mozilla rocks... I accidently clicked on horse pron
on stileproject and it crashed before displaying it

nicolas vigier s'est exprimé en ces termes:

Non, ca n'etait pas des packages officiels. Et qu'y a il de si pourri dans
le format RPM, tu peux donner un peu plus de details ?

Il lui manque une gestion des "suggest" ou des "recommend" par exemple.
Et une gestion de dépendances sur un package A _ou_ un package B.

Et pour d'autres idées :
<http://www.germane-software.com/~ser/Files/Essays/RPM_Hell.html>


--
<polaris> haha... mozilla rocks... I accidently clicked on horse pron
on stileproject and it crashed before displaying it

Le Fri, 11 Jun 2004 08:34:14 +0000, Nicolas George a écrit :

(snip)

Maintenant, examinons les implications de ce que tu proposes :

- Si tu considères Gtk+ 2, Qt, KDE, Gnome comme des bibliothèques
annexes, les programmes doivent les inclure, et tu multiplies ainsi
par dix ou vingt la taille de chaque programme à télécharger.

- Si tu considères ces bibliothèques comme des composants essentiels du
système, tu exiges qu'ils soient figés dans une vieille version pour
assurer la compatibilité. Ce n'est pas acceptable.

Pourquoi?

Le problème de l'installation des logiciels sous Linux vient justement de
la multiplicité des distributions, avec leurs versions différentes des
libs.
De même, deux machines avec la même distribution installée ne
contiendront plus les mêmes versions des libs car dans l'une on
installera un programme qui nécessitera une mise à niveau partielle du
système.

De ce fait, je ne m'étonne pas que l'installation des programmes reste un
des points noirs de Linux.

Pour simplifier, l'idée serait de définir un "socle commun" standard.
Ainsi, l'utilisateur et le programmeur sauraient que les distributions
estampillées "Socle Commun Linux" version n contiennent de fait tout ce
qu'il faut pour faire tourner les programmes qui lui sont dédiés, la
gestion des dépendances se faisant en amont.

<Rengaine>
En fait, ce qui se fait sur tous les autres OS...
</Rengaine>

Il y a eu la tentative LSB, mais elle semble actuellement morte...

D'une manière générale, il y a un point dont on ne sort pas, et je
l'avais d'ailleurs déjà énoncé la dernière fois que cette
discussion était sortie, je ne sais plus si c'est avec toi :

C'était avec moi ;-)

--
Jerome.