> lib/transaction.c c'est marqué dedans à 2 reprises.
Je me suis profondément plongé dans le code source. Tâche grandement pénible.
J'ai bien vérifié et effectivement, tu as raison.
A mon grand désespoir. Pas le fait d'avoir tord fasse à toi (quoique :-)), mais je trouve abérant qu'on puisse écraser un fichier par une fichier différent sans le moindre warning ou option "--force". Cela ressemble à un workaround à la petit semaine.
> En fait, y'a un cas pour les updates, un autre quand tu fais une installe pure (-i).
En gros dans tous les cas :-)
> T'avais l'air pourtant à fond Red Hat, je ne comprends pas comment tu n'aies pas pu voir cela.
Moi non plus. Les bug report sur ce point sont "confidentiels".
J'ai fouillé rapidement mes archives de mailing Fedora et je n'ai pas trouvé de discussion sur ce point.
> Mais bon sang, l'exemple du gars qui n'a pas eu de réponse pour ce cas là, émettait l'hypothèse de savoir comment c'était géré dans Fedora pour "glib-devel" !
Désolé, je ne t'ai pas compris. Je croyais que tu me reprochais de ne pas avoir regardé "glib-devel" de Mandriva. Et comme je l'ai dit, ce paquet n'existe pas.
Je n'ignore pas que Fedora n'est pas la perfection en développement biarch, mon soucis était de savoir comme Mandriva fesait et compte-tenu de ma connaissance de Mandriva je ne comprenais pas.
> glib-devel dans Fedora c'est glib 1.2.10.
Oui. Mais je ne pensais pas que tu faisais une fixation sur la version 1.2. Il y a glib-devel et glib2-devel. J'ai regardé pour glib version 2 car c'est la version en cours. C'est tout.
> Dans Mandriva, tu vois pourtant un package libglib1.2-devel et lib64glib1.2-devel.
Très bien, mais je ne vais pas regarder pour une version de librairie bientôt obsolette.
> Ah ben si quand même, y'a que ceux là (+ un include) qui diffèrent, donc tu les sépares de sorte qu'une installation simultanée des 2 ne puisse conflicter.
Oui et non. Si les *-devel n'ont pas la même version-release (ce que tu envisageais) ce n'est pas suffisant. Je doute qu'il n'y ait de risque à mélanger glib-2.6.1 et glib-2.6.4.
Exemple :
- installation glib-devel-2.6.4 (x86_64) et glib-devel-2.6.1 (i386)
Dans ce cas, les /usr/include et autre /usr/share sont ceux de x86_64 (""grace"" à rpm).
Donc pour i386, tu compiles avec les entêtes 2.6.4 et fait l'édition de lien avec 2.6.1.
C'est pas très rigoureux/généric. Je ne jète pas la pierre à Mandriva.
Il faut que les librairies soient développer en conséquence (par exemple /usr/bin/glib-genmarshal ne doit faire que du arch-indépendant (ce qui est le cas)).
> Par ailleurs, le rpm x86_64 de Fedora/RH n'a aucune config 32-bit pour compiler (cf. les /usr/lib/rpm/i386-linux/macros & co).
Tout a fait. Il n'y a pas vraiment de support pour compiler du 32-bit sur amd64.
Faut installer gcc et les lib*-devel en i386.
Pour RHEL, c'est un poil différent car il y a une "infrastructure" pour compiler pour plusieurs versions de RHEL (RHEL 3 & 4 avec i386 et amd64, etc). Mais ça passe par un chroot et ce n'est pas le propos de ce thread. C'est beaucoup plus lourd.
Je n'ai jamais utilisé ça, c'est une sorte de concurrent de mach (que Red Hat n'a pas repris pour des bonnes raisons (sans remettre en cause mach) mais que j'ai oublié ; désolé).
> Je ne vois pas pourquoi tu sors ça.
OK, j'ai dit une connerie et pas qu'une.
Ça m'arrive. Mais trop de fois on a vu des "pro-Mandrake" promettre la lune alors qu'il n'y avait rien de nouveau. J'avais à tord dans ce thread un préjugé négatif et je m'en excuse. Maintenant je ne peux que reconnaitre que Mandriva a fait un travail intéressant et utile. Ce travail ne mérite pas mes commentaires précédents.
> Bon, tu ne veux pas télécharger et essayer par toi même?
Non. Mais ne t'inquiète pas, je le redis, Mandriva a fait du bon boulot et est allé au-delà de ce que fait RH/Fedora. Il me semble que j'ai maintenant compris ce qu'a fait Mandriva est les gains qu'on peut en tirer.
> Au fait, linux32 rpm --rebuild truc.rpm ne fonctionnera pas sous Fedora parce que tu aurais besoin en plus de spécificier CC="gcc -m32" et éventuellement CXX="g++ -m32".
Je n'étais pas dans cette optique. Je pensais à compilateur et *-devel en i386.
Effectivement, gcc de Mandriva est patché (gcc34-biarch-personality.patch).
> Mandrake n'a rien inventé
> Où ai-je dit que Mandrake a créé l'outil linux32? Bon sang, mais t'es terrible toi pour détourner les propos des gens. Le plus drôle (vraiment c'est comique là parce que tu es un spécimen) c'est que tu sors après tout un tas de patches, docs sur un truc insignifiant qui n'a rien à voir avec le propos initial. Juste avec un propos que tu as mal interprété ou bien détourné de sens encore une fois.
T'as raison de t'énervé, mais n'en profite pas trop :-)
[^] # Re: Et le plus important...
Posté par fabb . En réponse au journal Mandriva Linux Limited Edition 2005 released. Évalué à 2.
Je me suis profondément plongé dans le code source. Tâche grandement pénible.
J'ai bien vérifié et effectivement, tu as raison.
A mon grand désespoir. Pas le fait d'avoir tord fasse à toi (quoique :-)), mais je trouve abérant qu'on puisse écraser un fichier par une fichier différent sans le moindre warning ou option "--force". Cela ressemble à un workaround à la petit semaine.
> En fait, y'a un cas pour les updates, un autre quand tu fais une installe pure (-i).
En gros dans tous les cas :-)
> T'avais l'air pourtant à fond Red Hat, je ne comprends pas comment tu n'aies pas pu voir cela.
Moi non plus. Les bug report sur ce point sont "confidentiels".
J'ai fouillé rapidement mes archives de mailing Fedora et je n'ai pas trouvé de discussion sur ce point.
> Mais bon sang, l'exemple du gars qui n'a pas eu de réponse pour ce cas là, émettait l'hypothèse de savoir comment c'était géré dans Fedora pour "glib-devel" !
Désolé, je ne t'ai pas compris. Je croyais que tu me reprochais de ne pas avoir regardé "glib-devel" de Mandriva. Et comme je l'ai dit, ce paquet n'existe pas.
Je n'ignore pas que Fedora n'est pas la perfection en développement biarch, mon soucis était de savoir comme Mandriva fesait et compte-tenu de ma connaissance de Mandriva je ne comprenais pas.
> glib-devel dans Fedora c'est glib 1.2.10.
Oui. Mais je ne pensais pas que tu faisais une fixation sur la version 1.2. Il y a glib-devel et glib2-devel. J'ai regardé pour glib version 2 car c'est la version en cours. C'est tout.
> Dans Mandriva, tu vois pourtant un package libglib1.2-devel et lib64glib1.2-devel.
Très bien, mais je ne vais pas regarder pour une version de librairie bientôt obsolette.
> Ah ben si quand même, y'a que ceux là (+ un include) qui diffèrent, donc tu les sépares de sorte qu'une installation simultanée des 2 ne puisse conflicter.
Oui et non. Si les *-devel n'ont pas la même version-release (ce que tu envisageais) ce n'est pas suffisant. Je doute qu'il n'y ait de risque à mélanger glib-2.6.1 et glib-2.6.4.
Exemple :
- installation glib-devel-2.6.4 (x86_64) et glib-devel-2.6.1 (i386)
Dans ce cas, les /usr/include et autre /usr/share sont ceux de x86_64 (""grace"" à rpm).
Donc pour i386, tu compiles avec les entêtes 2.6.4 et fait l'édition de lien avec 2.6.1.
C'est pas très rigoureux/généric. Je ne jète pas la pierre à Mandriva.
Il faut que les librairies soient développer en conséquence (par exemple /usr/bin/glib-genmarshal ne doit faire que du arch-indépendant (ce qui est le cas)).
> Par ailleurs, le rpm x86_64 de Fedora/RH n'a aucune config 32-bit pour compiler (cf. les /usr/lib/rpm/i386-linux/macros & co).
Tout a fait. Il n'y a pas vraiment de support pour compiler du 32-bit sur amd64.
Faut installer gcc et les lib*-devel en i386.
Pour RHEL, c'est un poil différent car il y a une "infrastructure" pour compiler pour plusieurs versions de RHEL (RHEL 3 & 4 avec i386 et amd64, etc). Mais ça passe par un chroot et ce n'est pas le propos de ce thread. C'est beaucoup plus lourd.
Je n'ai jamais utilisé ça, c'est une sorte de concurrent de mach (que Red Hat n'a pas repris pour des bonnes raisons (sans remettre en cause mach) mais que j'ai oublié ; désolé).
> Je ne vois pas pourquoi tu sors ça.
OK, j'ai dit une connerie et pas qu'une.
Ça m'arrive. Mais trop de fois on a vu des "pro-Mandrake" promettre la lune alors qu'il n'y avait rien de nouveau. J'avais à tord dans ce thread un préjugé négatif et je m'en excuse. Maintenant je ne peux que reconnaitre que Mandriva a fait un travail intéressant et utile. Ce travail ne mérite pas mes commentaires précédents.
> Bon, tu ne veux pas télécharger et essayer par toi même?
Non. Mais ne t'inquiète pas, je le redis, Mandriva a fait du bon boulot et est allé au-delà de ce que fait RH/Fedora. Il me semble que j'ai maintenant compris ce qu'a fait Mandriva est les gains qu'on peut en tirer.
> Au fait, linux32 rpm --rebuild truc.rpm ne fonctionnera pas sous Fedora parce que tu aurais besoin en plus de spécificier CC="gcc -m32" et éventuellement CXX="g++ -m32".
Je n'étais pas dans cette optique. Je pensais à compilateur et *-devel en i386.
Effectivement, gcc de Mandriva est patché (gcc34-biarch-personality.patch).
> Mandrake n'a rien inventé
> Où ai-je dit que Mandrake a créé l'outil linux32? Bon sang, mais t'es terrible toi pour détourner les propos des gens. Le plus drôle (vraiment c'est comique là parce que tu es un spécimen) c'est que tu sors après tout un tas de patches, docs sur un truc insignifiant qui n'a rien à voir avec le propos initial. Juste avec un propos que tu as mal interprété ou bien détourné de sens encore une fois.
T'as raison de t'énervé, mais n'en profite pas trop :-)