Donnes au moins le nom fichier puisque c'est si évident pour toi.
lib/transaction.c c'est marqué dedans à 2 reprises. En fait, y'a un cas pour les updates, un autre quand tu fais une installe pure (-i).
Non. En cas de comflit, rpm s'arrête. rpm est un outils bas niveau et pas "smart".
Regarde les sources ou bien lis au moins le changelog. T'avais l'air pourtant à fond Red Hat, je ne comprends pas comment tu n'aies pas pu voir cela.
l n'y a pas de paquet glib-devel dans Mandriva LE 2005 !
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" ! glib-devel dans Fedora c'est glib 1.2.10. Dans Mandriva, tu vois pourtant un package libglib1.2-devel et lib64glib1.2-devel.
Ce n'est pas suffisant. Vraiment pas.
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. Pour glib2, comme expliqué, avec le système de résolution implicite des conflits pour elf64/elf32 ça s'installe. Par chance, tu auras remarqué que ce que ça fait est arch-indépendant, pour glib2 je le précise encore, pour 32 ou 64-bit. Tout simplement parce que ça génère du code C et l'implémentation réelle du marshaling sera déportée par petits bouts dans les libs respectives une fois le code généré compilé.
Comme Red Hat, mais t'as seulement les *-devel i386 ou amd64 d'installé à la foi. Et c'est idem pour Mandriva !
Je t'explique depuis le temps que sous Mandriva, tu installes les 2 à la fois. Bon, tu ne veux pas télécharger et essayer par toi même? Parce que je m'efforce à t'expliquer mais tu ne comprends toujours pas. Essaie, ce sera sans doute limpide...
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". Pas besoin sous Mandriva. ;-) GCC et d'autres outils ont été patchés pour être linux32 aware.
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).
man linux32
Je ne vois pas pourquoi tu sors ça. linux32 te permets de spécifier une personnalité 32-bit. De fait, rpm quand il fera son uname -m saura que c'est i686 et donc chopera les configs 32-bit pour compiler.
Pour ton info, linux32 de x86-64.org était utilisé initialement utilisé. C'est un programme trivial cela dit au passage, donc inutile d'en réécrire un pour chaque distrib. Celui de x86-64.org était écrit par SuSE. Bon après, setarch est apparu pour couvrir plus d'architectures.
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.
[^] # Re: Et le plus important...
Posté par Gwenole Beauchesne . En réponse au journal Mandriva Linux Limited Edition 2005 released. Évalué à 2.
lib/transaction.c c'est marqué dedans à 2 reprises. En fait, y'a un cas pour les updates, un autre quand tu fais une installe pure (-i).
Non. En cas de comflit, rpm s'arrête. rpm est un outils bas niveau et pas "smart".
Regarde les sources ou bien lis au moins le changelog. T'avais l'air pourtant à fond Red Hat, je ne comprends pas comment tu n'aies pas pu voir cela.
l n'y a pas de paquet glib-devel dans Mandriva LE 2005 !
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" ! glib-devel dans Fedora c'est glib 1.2.10. Dans Mandriva, tu vois pourtant un package libglib1.2-devel et lib64glib1.2-devel.
Ce n'est pas suffisant. Vraiment pas.
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. Pour glib2, comme expliqué, avec le système de résolution implicite des conflits pour elf64/elf32 ça s'installe. Par chance, tu auras remarqué que ce que ça fait est arch-indépendant, pour glib2 je le précise encore, pour 32 ou 64-bit. Tout simplement parce que ça génère du code C et l'implémentation réelle du marshaling sera déportée par petits bouts dans les libs respectives une fois le code généré compilé.
Comme Red Hat, mais t'as seulement les *-devel i386 ou amd64 d'installé à la foi. Et c'est idem pour Mandriva !
Je t'explique depuis le temps que sous Mandriva, tu installes les 2 à la fois. Bon, tu ne veux pas télécharger et essayer par toi même? Parce que je m'efforce à t'expliquer mais tu ne comprends toujours pas. Essaie, ce sera sans doute limpide...
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". Pas besoin sous Mandriva. ;-) GCC et d'autres outils ont été patchés pour être linux32 aware.
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).
man linux32
Je ne vois pas pourquoi tu sors ça. linux32 te permets de spécifier une personnalité 32-bit. De fait, rpm quand il fera son uname -m saura que c'est i686 et donc chopera les configs 32-bit pour compiler.
Pour ton info, linux32 de x86-64.org était utilisé initialement utilisé. C'est un programme trivial cela dit au passage, donc inutile d'en réécrire un pour chaque distrib. Celui de x86-64.org était écrit par SuSE. Bon après, setarch est apparu pour couvrir plus d'architectures.
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.