Tu voudras sans doute utiliser la version 32-bit de PLF. Certains packages contiennent des optimisations spécifiques MMX, SSE qui sont directement écrits en assembleur inline. Si le développeur n'a pas utilisé des intrinsics proprement, ou bien prévu le coup pour les modes d'adressage x86_64, ben ces optimisations ne passent pas donc ça utilise du code générique.
"Red Hat and AMD will demonstrate the 32-bit Red Hat Linux Advanced Server operating system on a 64-bit AMD Athlon processor based on Hammer technology at LinuxWorld 2002, San Francisco August 13-15 (AMD Booth #747)."
i.e. ils n'avaient pas encore de version 64-bit à montrer, alors que SuSE et Mandrakesoft si.
> Si, comme tu le sous-entends plus loins, Red Hat a la main mise sur gcc, alors Red Hat a fait le portage de gcc pour AMD64 (ce qui est le plus difficile (au moins techniquement) à réaliser). Faut choisir.
Il n'y a aucun raisonnement logique dans cette hypothèse. Je t'ai déjà dit plusieurs fois que c'était SuSE qui l'a fait. Y compris pour kernel, glibc, xf86. Au moins un bonhomme chaque (Jan, Andi, Andreas, Egbert). J'ai l'impression que quand je parle de SuSE, tu penses MDK. M'enfin bon.
Les premières plate-formes matérielles à être "largement" diffusées sont apparues vers Q2 2002. Auparavant SuSE travaillait d'abord via SimNow!, puis Simics qui est plus rapide. FreeBSD était développé sous Simics aussi d'ailleurs. En d'autres termes, il fallait être très patient. i.e. le portage d'une distribution complète était conditionné par le déploiement des plate-formes matérielles en quelque sorte.
Il faut arrêter de croire que tout débute par Red Hat. Pour l'AMD64, c'était clairement SuSE. D'ailleurs AMD les payait pour le faire justement, si je me rappelle bien. J'espère que tu saisis maintenant.
> Prends gcc ou Linux et regardes le nombre de modif faites par Red Hat. C'est ça qui compte.
Bon sang, lis tout s'il te plaît. C'est normal que Red Hat travaille beaucoup plus que quiconque sur GCC, ils ont phagocyté Cygnus. Pour x86_64, je te redis encore que le portage est fait par SuSE (spécification et implémentation de l'ABI), et c'est toujours eux qui le maintiennent en grande partie. Ensuite, il existe des corrections de bugs habituels, comme sur n'importe quelle distrib, sur n'importe quelle architecture avec l'évolution des versions, etc.
> Red Hat And AMD Announce Red Hat Linux Advanced Server Operating System For AMD's Hammer Technology
Et puis as-tu vraiment vu ce produit tourner au moment de l'annonce de l'intention de supporter RHAS sur x86_64? C'est ça la différence. Sur quels shows RHAS x86_64 a-t-il été montré? Remarque en outre, que Mandrakesoft faisait également des démos de la distrib aux US, sur le stand AMD.
Tu sais, Apple avait également annoncé l'ordinateur personnel le plus rapide au monde. Mais là, je tombe dans le troll. ;-)
Mandrakesoft a commencé en mai 2002, et il y avait déjà des démos sur divers salons, notamment Linux World 2002 à Frankfurt (une 9.0).
Pour kernel/gcc/glibc/xf86, j'ai explicitement parlé de SuSE + AMD, si tu pouvais relire. D'ailleurs, je pense que tu n'as pas du lire les docs de SuSE pour le portage de ces outils.
Il existait zéro support x86_64/amd64 dans rpm quand SuSE et Mandrakesoft ont commencé.
Il n'y a rien de fait initialement et de manière significative par Red Hat concernant le kernel/gcc/glibc/xf86 sur x86_64. C'est SuSE + AMD. C'est une chose.
L'autre chose, c'est la correction des programmes pour 64-bit + lib64 + spécificités mises en exergue sur x86_64. Là, Mandrakesoft était un acteur important: Mozilla, Kaffe, OOo au début, etc. et plus d'une centaine de fixes 64-bit par distrib en moyenne. Même pour gnome2 c'était SuSE et MDK, c'est dire...
Il est possible de générer du code 32-bit en utilisant les registres supplémentaires. Par contre, il faut créer une nouvelle ABI ILP32 pour que ce soit plus intéressant. Un peut comme les modes o32/n32 sur IRIX/mips. Ca induit de patcher kernel, binutils, gcc, glibc.
L'intérêt est une meilleure occupation du cache mais si le gain est inférieur à 5%, à mon avis, ça ne vaut pas l'effort. Si ça se fait en toy project, Mandrakelinux est très facilement retargetable en plate-forme triarch au niveau packaging. ;-)
L'Itanium n'est pas incompatible avec l'existant. OpenOffice.org et Mozilla 32-bit fonctionnent très bien grâce à l'émulateur IA-32 intégré au processeur. Sur des processeurs récents dépourvu de l'émulateur hard, il existe une solution logicielle plus rapide: IA-32 EL. C'est également disponible sous Linux. Les performances mesurées sont de l'ordre de 70% en moyenne d'un Xeon cadencé à la même fréquence.
En fait le plug-in Flash 32-bit tourne avec un Konqueror 64-bit et un nsplugins 32-bit. Cela parce que le support des plug-ins type Netscape4 dans Konqueror se fait via un processus séparé, qui peut donc être 32-bit.
Il existe également un JDK 1.4.2 pour x86-64. D'ailleurs la nouvelle -fcs est disponible sur les miroirs depuis fin septembre. Le plug-in OJI mozilla 64-bit ne fonctionnera pas avec les distribs compilées avec GCC 3.4. Ce sera normalement possible avec la prochaine release du 1.4.2 et les autres 1.5.0 fournies par Blackdown.org.
SuSE et Mandrakelinux depuis 1 an et demi au moins. En fait, ils étaient d'ailleurs respectivement les premier et deuxième acteurs à soutenir Linux/AMD64 en fournissant des distributions natives 64-bit. Red Hat est venue après.
Ca dépend de l'algo 7zip utilisé. Je crois que des versions récentes utilisent du PPMd qui donne de très bons résultats. Autrement LZMA doit être une n-ième variante de LZ77 avec tampon plus grand c'est tout.
L'implémentation de bzip2 commence effectivement à veillir mais cela reste tout à fait raisonnable. BWT est vieux en lui même, ce qui change c'est l'implémentation d'un tri rapide.
De nos jours, on devrait (enfin) pouvoir populariser des variantes PPM et exploiter différents modèles selon le contenu des fichiers pour obtenir des taux de compression supérieurs.
C'est pareil je crois aux USA d'où l'utilisation de subterfuges linguistiques comme "method", "apparatus", etc. De même ils arrivent aussi à breveter plusieurs fois la même chose...
Et puis au fait, que je sache, il n'existe pas de brevet sur le format GIF, mais plusieurs brevets sur les méthodes de compression de type LZW.
Le comité de normalisation ISO qui s'occupe de JPEG 2000 a demandé aux détenteurs de brevets couvrant la première partie de JPEG 2000, ne demandent aucune royalties pour des implémentations de JPEG2000. De fait, par exemple, IBM a gracieusement offert leur VQ coder mais uniquement dans le cadre d'une implémentation de JPEG2000.
Si libtest1-2.1-1mdk.i586.rpm était utilisé, la mise à jours de la lib x86_64 serait refusée et libtest1-2.1-1mdk.i586.rpm ne serait pas viré
Tu avoues donc que par ce biais tu perds l'indépendance des mises à jour de packages en environnement biarch. D'où l'intérêt d'avoir des packages de bibliothèques nommés différemment.
Effectivement, même si je ne suis pas d'accord avec ce comportement car les packages amd64/i586 doivent pouvoir vivre indépendament d'une architecture à l'autre:
[gb@galois T]$ sudo rpm -Fvh test-x86_64-2.1-2mdk.amd64.rpm libtest1-2.1-2mdk.amd64.rpm
error: Failed dependencies:
libtest.so.0 is needed by (installed) test-i386-2.1-1mdk
Et tu vois ensuite tout de suite que,
[gb@galois T]$ sudo rpm -Fvh *2.1-2mdk*.rpm
Preparing... ########################################### [100%]
1:libtest1 ########################################### [ 25%]
2:libtest1 ########################################### [ 50%]
3:test-i386 ########################################### [ 75%]
4:test-x86_64 ########################################### [100%]
[gb@galois T]$ rpm -qa --qf "%{name}-%{version}.%{arch}\n" "*test*"
libtest1-2.1.amd64
libtest1-2.1.i586
test-i386-2.1.i586
test-x86_64-2.1.amd64
Bref, il faut donc la même version-release du package de libs avec la méthode rpm standard, comme initialement indiqué.
> Par ailleurs, quand ensuite tu veux *mettre à jour* l'un des packages ben tu étais couillonné: l'autre instance disparaissait de la base rpm.
Faux. Par contre, comme au-dessus on ne peut pas faire tout et n'importe quoi. Si en biarch une librairie a des fichiers de conf en dure, il faut exactement la même version-release. Ce n'est pas une contrainte rpm.
Je suis sûr que tu as répondu cela après avoir essayé, n'est-ce pas?
[gb@galois T]$ rpm --version
RPM version 4.2.2
[gb@galois T]$ ls
libtest1-2.1-1mdk.amd64.rpm libtest1-2.1-2mdk.amd64.rpm libtest1-2.2-1mdk.amd64.rpm
libtest1-2.1-1mdk.i586.rpm libtest1-2.1-3mdk.i586.rpm
[gb@galois T]$ ls /usr/lib/libtest*
ls: /usr/lib/libtest*: No such file or directory
[gb@galois T]$ ls /usr/lib64/libtest*
/usr/lib64/libtest.so@ /usr/lib64/libtest.so.0@ /usr/lib64/libtest.so.0.0*
Je parle des "Requires:" dans le fichier spec. Ils sont ajouté manuellement.
Ben oui, quel robot pourrait trouver que libtool >= 1.4.3-5mdk dans rpm-build soit nécessaire pour que le build de packages amd64 fonctionne décemment?
J'ai regardé find-req.pl et c'est une connerie de faire ça. Ça ajoute des dépendances inutiles. Si un programme a uniquement besoin de libX11.so je ne vois pas pourquoi il faut ajouter libc puisque le paquet qui fournit libX11.so a déjà cette dépendance. Aucun intérêt. C'est uniquement pour empêcher l'installation sur une autre bécane.
Tes deux dernières phrases entrent en conflit. D'une part, un programme ne peut avoir besoin que de libX11.so.6. D'autre part, si le programme dépend de libX11.so.6, libc.so.6, libm.so.6, tu vois trivialement dans le package qui fournit libX11.so.6, qu'il dépend également de libc.so.6, donc la dépendence sur libc.so.6 pour le programme d'origine, n'empêche nullement l'installation sur une autre bécane. De plus, un programme ne peut dépendre de libX11.so tout court, vu que libX11.so est le linkname, et ce qu'il y a dans les entrées DT_NEEDED du programme ce sont les libs qui ont des SONAMEs idoines.
Avec Mandrake au-lieu d'avoir un simple "Requires: libtoto.so.0" (fait automatiquement) il y a aussi "Requires: libtoto0".
Précise pour quel package car il ne doit plus en rester telles que "Requires: libtoto0", sauf s'il faut une dépendence explicite sur une certaine libtoto0. e.g. Requires: %{libtoto} = version-release, ou %{libtoto} >= version (plus rare mais là on c'est qu'on est sûr que c'est binary compatible depuis cette version).
> C'est RedHat qui a ajouté ce support (rpm V4.2).
Qui ne marche pas correctement. Si le package n'est pas correctement libifié, tu peux avoir des conflits par exemple juste à cause des %doc. De même, rpm ne gérait des installs de packages biarch que s'ils avaient la même version-release exactement. Par ailleurs, quand ensuite tu veux *mettre à jour* l'un des packages ben tu étais couillonné: l'autre instance disparaissait de la base rpm.
Au fait, j'indique au passage que la version officielle de rpm 4.2.2 n'est pas triviale à trouver, i.e. ce n'est pas celle de rpm.org. De même le développement de rpm 4.2 est postérieur au début du développement de Mandrakelinux pour amd64 (vers mai 2002). Donc, il fallait une solution simple et triviale à gérer pour maximiser la flexibilité. Par exemple, si je voulais une nouvelle ABI 32-bit, les packages de lib correspondant s'appelleraient lib32bidule.
Par ailleurs, il est intéressant de noter que même RedHat commence à libifier un peu ses packages de sorte à limiter les conflits possible lors d'installation de packages ia32/amd64 en parallèle.
Sous Mandrakelinux, tu peux installer n'importe quel lot de packages libifiés sans aucun conflit et qui peuvent être mis à jour indépendamment, l'un de l'autre. C'est pratique quand tu veux un package ia32 qui dépend d'une lib plus récente ou plus ancienne, qui n'existe pas parallèlement en natif.
[^] # Re: Build scripts?
Posté par Gwenole Beauchesne . En réponse à la dépêche AMD64 vs Intel32 : 30% d'écart !. Évalué à 1.
[^] # Re: Build scripts?
Posté par Gwenole Beauchesne . En réponse à la dépêche AMD64 vs Intel32 : 30% d'écart !. Évalué à 2.
Et
> * August 13, 2002
> Red Hat And AMD Announce Red Hat Linux Advanced Server Operating System For AMD's Hammer Technology
Tu veux sans doute parler de:
http://www.amd.com/us-en/Weblets/0,,7832_8366_7595~41287,00.html(...)
"Red Hat and AMD will demonstrate the 32-bit Red Hat Linux Advanced Server operating system on a 64-bit AMD Athlon processor based on Hammer technology at LinuxWorld 2002, San Francisco August 13-15 (AMD Booth #747)."
i.e. ils n'avaient pas encore de version 64-bit à montrer, alors que SuSE et Mandrakesoft si.
> Si, comme tu le sous-entends plus loins, Red Hat a la main mise sur gcc, alors Red Hat a fait le portage de gcc pour AMD64 (ce qui est le plus difficile (au moins techniquement) à réaliser). Faut choisir.
Il n'y a aucun raisonnement logique dans cette hypothèse. Je t'ai déjà dit plusieurs fois que c'était SuSE qui l'a fait. Y compris pour kernel, glibc, xf86. Au moins un bonhomme chaque (Jan, Andi, Andreas, Egbert). J'ai l'impression que quand je parle de SuSE, tu penses MDK. M'enfin bon.
Les premières plate-formes matérielles à être "largement" diffusées sont apparues vers Q2 2002. Auparavant SuSE travaillait d'abord via SimNow!, puis Simics qui est plus rapide. FreeBSD était développé sous Simics aussi d'ailleurs. En d'autres termes, il fallait être très patient. i.e. le portage d'une distribution complète était conditionné par le déploiement des plate-formes matérielles en quelque sorte.
Il faut arrêter de croire que tout débute par Red Hat. Pour l'AMD64, c'était clairement SuSE. D'ailleurs AMD les payait pour le faire justement, si je me rappelle bien. J'espère que tu saisis maintenant.
[^] # Re: Build scripts?
Posté par Gwenole Beauchesne . En réponse à la dépêche AMD64 vs Intel32 : 30% d'écart !. Évalué à 2.
Bon sang, lis tout s'il te plaît. C'est normal que Red Hat travaille beaucoup plus que quiconque sur GCC, ils ont phagocyté Cygnus. Pour x86_64, je te redis encore que le portage est fait par SuSE (spécification et implémentation de l'ABI), et c'est toujours eux qui le maintiennent en grande partie. Ensuite, il existe des corrections de bugs habituels, comme sur n'importe quelle distrib, sur n'importe quelle architecture avec l'évolution des versions, etc.
> Red Hat And AMD Announce Red Hat Linux Advanced Server Operating System For AMD's Hammer Technology
Et puis as-tu vraiment vu ce produit tourner au moment de l'annonce de l'intention de supporter RHAS sur x86_64? C'est ça la différence. Sur quels shows RHAS x86_64 a-t-il été montré? Remarque en outre, que Mandrakesoft faisait également des démos de la distrib aux US, sur le stand AMD.
Tu sais, Apple avait également annoncé l'ordinateur personnel le plus rapide au monde. Mais là, je tombe dans le troll. ;-)
[^] # Re: Build scripts?
Posté par Gwenole Beauchesne . En réponse à la dépêche AMD64 vs Intel32 : 30% d'écart !. Évalué à 3.
http://www.amd.com/us-en/Weblets/0,,7832_8366_7595~56764,00.html(...)
Linux World à la même date:
http://www.mandrakesoft.com/company/community/mandrakesoftnews/news(...)
[^] # Re: Build scripts?
Posté par Gwenole Beauchesne . En réponse à la dépêche AMD64 vs Intel32 : 30% d'écart !. Évalué à 1.
Pour kernel/gcc/glibc/xf86, j'ai explicitement parlé de SuSE + AMD, si tu pouvais relire. D'ailleurs, je pense que tu n'as pas du lire les docs de SuSE pour le portage de ces outils.
[^] # Re: Build scripts?
Posté par Gwenole Beauchesne . En réponse à la dépêche AMD64 vs Intel32 : 30% d'écart !. Évalué à 1.
Il n'y a rien de fait initialement et de manière significative par Red Hat concernant le kernel/gcc/glibc/xf86 sur x86_64. C'est SuSE + AMD. C'est une chose.
L'autre chose, c'est la correction des programmes pour 64-bit + lib64 + spécificités mises en exergue sur x86_64. Là, Mandrakesoft était un acteur important: Mozilla, Kaffe, OOo au début, etc. et plus d'une centaine de fixes 64-bit par distrib en moyenne. Même pour gnome2 c'était SuSE et MDK, c'est dire...
[^] # Re: AMD64 ou autre raison ?
Posté par Gwenole Beauchesne . En réponse à la dépêche AMD64 vs Intel32 : 30% d'écart !. Évalué à 1.
[^] # Re: AMD64 ou autre raison ?
Posté par Gwenole Beauchesne . En réponse à la dépêche AMD64 vs Intel32 : 30% d'écart !. Évalué à 3.
L'intérêt est une meilleure occupation du cache mais si le gain est inférieur à 5%, à mon avis, ça ne vaut pas l'effort. Si ça se fait en toy project, Mandrakelinux est très facilement retargetable en plate-forme triarch au niveau packaging. ;-)
[^] # Re: 30% d'écart : voulu !
Posté par Gwenole Beauchesne . En réponse à la dépêche AMD64 vs Intel32 : 30% d'écart !. Évalué à 1.
[^] # Re: Build scripts?
Posté par Gwenole Beauchesne . En réponse à la dépêche AMD64 vs Intel32 : 30% d'écart !. Évalué à 2.
[^] # Re: Build scripts?
Posté par Gwenole Beauchesne . En réponse à la dépêche AMD64 vs Intel32 : 30% d'écart !. Évalué à 2.
Il existe également un JDK 1.4.2 pour x86-64. D'ailleurs la nouvelle -fcs est disponible sur les miroirs depuis fin septembre. Le plug-in OJI mozilla 64-bit ne fonctionnera pas avec les distribs compilées avec GCC 3.4. Ce sera normalement possible avec la prochaine release du 1.4.2 et les autres 1.5.0 fournies par Blackdown.org.
[^] # Re: Build scripts?
Posté par Gwenole Beauchesne . En réponse à la dépêche AMD64 vs Intel32 : 30% d'écart !. Évalué à 2.
[^] # Re: Toujours du RPM...
Posté par Gwenole Beauchesne . En réponse à la dépêche Sortie du Linux Standard Base 2.0. Évalué à 4.
L'implémentation de bzip2 commence effectivement à veillir mais cela reste tout à fait raisonnable. BWT est vieux en lui même, ce qui change c'est l'implémentation d'un tri rapide.
De nos jours, on devrait (enfin) pouvoir populariser des variantes PPM et exploiter différents modèles selon le contenu des fichiers pour obtenir des taux de compression supérieurs.
[^] # Re: 2 architectures
Posté par Gwenole Beauchesne . En réponse à la dépêche Nouveaux pilotes nvidia 6106. Évalué à 1.
[^] # Re: GCC et Altivec
Posté par Gwenole Beauchesne . En réponse à la dépêche Mac OS X et les technologies du libre. Évalué à 3.
[^] # Re: re
Posté par Gwenole Beauchesne . En réponse à la dépêche Sortie de WineX 4.0. Évalué à 3.
[^] # Re: Y'avait deja des brevets en France ?
Posté par Gwenole Beauchesne . En réponse à la dépêche Le brevet sur le format GIF est arrivé à expiration. Évalué à 1.
Et puis au fait, que je sache, il n'existe pas de brevet sur le format GIF, mais plusieurs brevets sur les méthodes de compression de type LZW.
[^] # Re: Dommage
Posté par Gwenole Beauchesne . En réponse à la dépêche Les images ISO "Mandrake 10.0 Official" disponibles au téléchargement. Évalué à 2.
[^] # Re: Le format JPEG sous le coup d'un brevet
Posté par Gwenole Beauchesne . En réponse à la dépêche Le format JPEG sous le coup d'un brevet. Évalué à 2.
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par Gwenole Beauchesne . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 2.
Juste un %doc mais comme c'est un %doc, ça ne conflicte pas de nos jours.
Donnes la sortie de "rpm -qlp libtest1-2.1-1mdk.amd64.rpm libtest1-2.1-1mdk.i586.rpm" avant que j'avoue mon erreur :-)
[gb@galois T]$ rpm -qlp libtest1-2.1-1mdk.amd64.rpm libtest1-2.1-1mdk.i586.rpm
/usr/lib64/libtest.so
/usr/lib64/libtest.so.0
/usr/lib64/libtest.so.0.0
/usr/share/doc/libtest1-2.1
/usr/share/doc/libtest1-2.1/main.c
/usr/lib/libtest.so
/usr/lib/libtest.so.0
/usr/lib/libtest.so.0.0
/usr/share/doc/libtest1-2.1
/usr/share/doc/libtest1-2.1/main.c
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par Gwenole Beauchesne . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 3.
Tu avoues donc que par ce biais tu perds l'indépendance des mises à jour de packages en environnement biarch. D'où l'intérêt d'avoir des packages de bibliothèques nommés différemment.
Bref, ça marche bien.
Voyons cela.
[gb@galois T]$ ls
libtest1-2.1-1mdk.amd64.rpm libtest1-2.1-2mdk.i586.rpm test-x86_64-2.1-1mdk.amd64.rpm
libtest1-2.1-1mdk.i586.rpm test-i386-2.1-1mdk.i586.rpm test-x86_64-2.1-2mdk.amd64.rpm
libtest1-2.1-2mdk.amd64.rpm test-i386-2.1-2mdk.i586.rpm
[gb@galois T]$ rpm -qlp test-x86_64-2.1-1mdk.amd64.rpm
/usr/bin/testapp.x86_64
[gb@galois T]$ rpm -qpR test-x86_64-2.1-1mdk.amd64.rpm
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libtest.so.0()(64bit)
[gb@galois T]$ sudo rpm -i *2.1-1mdk*
[gb@galois T]$ rpm -qa --qf "%{name}-%{version}.%{arch}\n" "*test*"
test-i386-2.1.i586
test-x86_64-2.1.amd64
libtest1-2.1.i586
libtest1-2.1.amd64
Effectivement, même si je ne suis pas d'accord avec ce comportement car les packages amd64/i586 doivent pouvoir vivre indépendament d'une architecture à l'autre:
[gb@galois T]$ sudo rpm -Fvh test-x86_64-2.1-2mdk.amd64.rpm libtest1-2.1-2mdk.amd64.rpm
error: Failed dependencies:
libtest.so.0 is needed by (installed) test-i386-2.1-1mdk
Et tu vois ensuite tout de suite que,
[gb@galois T]$ sudo rpm -Fvh *2.1-2mdk*.rpm
Preparing... ########################################### [100%]
1:libtest1 ########################################### [ 25%]
2:libtest1 ########################################### [ 50%]
3:test-i386 ########################################### [ 75%]
4:test-x86_64 ########################################### [100%]
[gb@galois T]$ rpm -qa --qf "%{name}-%{version}.%{arch}\n" "*test*"
libtest1-2.1.amd64
libtest1-2.1.i586
test-i386-2.1.i586
test-x86_64-2.1.amd64
Bref, il faut donc la même version-release du package de libs avec la méthode rpm standard, comme initialement indiqué.
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par Gwenole Beauchesne . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 6.
Faux. Par contre, comme au-dessus on ne peut pas faire tout et n'importe quoi. Si en biarch une librairie a des fichiers de conf en dure, il faut exactement la même version-release. Ce n'est pas une contrainte rpm.
Je suis sûr que tu as répondu cela après avoir essayé, n'est-ce pas?
[gb@galois T]$ rpm --version
RPM version 4.2.2
[gb@galois T]$ ls
libtest1-2.1-1mdk.amd64.rpm libtest1-2.1-2mdk.amd64.rpm libtest1-2.2-1mdk.amd64.rpm
libtest1-2.1-1mdk.i586.rpm libtest1-2.1-3mdk.i586.rpm
[gb@galois T]$ sudo rpm -ivh libtest1-2.1-1mdk.amd64.rpm
Preparing... ########################################### [100%]
1:libtest1 ########################################### [100%]
[gb@galois T]$ rpm -qa "libtest*"
libtest1-2.1-1mdk
[gb@galois T]$ sudo rpm -ivh libtest1-2.1-1mdk.i586.rpm
Preparing... ########################################### [100%]
1:libtest1 ########################################### [100%]
[gb@galois T]$ rpm -qa "libtest*"
libtest1-2.1-1mdk
libtest1-2.1-1mdk
[gb@galois T]$ sudo rpm -Fvh libtest1-2.1-2mdk.amd64.rpm
Preparing... ########################################### [100%]
1:libtest1 ########################################### [100%]
[gb@galois T]$ rpm -qa "libtest*"
libtest1-2.1-2mdk
[gb@galois T]$ ls /usr/lib/libtest*
ls: /usr/lib/libtest*: No such file or directory
[gb@galois T]$ ls /usr/lib64/libtest*
/usr/lib64/libtest.so@ /usr/lib64/libtest.so.0@ /usr/lib64/libtest.so.0.0*
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par Gwenole Beauchesne . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 5.
Ben oui, quel robot pourrait trouver que libtool >= 1.4.3-5mdk dans rpm-build soit nécessaire pour que le build de packages amd64 fonctionne décemment?
J'ai regardé find-req.pl et c'est une connerie de faire ça. Ça ajoute des dépendances inutiles. Si un programme a uniquement besoin de libX11.so je ne vois pas pourquoi il faut ajouter libc puisque le paquet qui fournit libX11.so a déjà cette dépendance. Aucun intérêt. C'est uniquement pour empêcher l'installation sur une autre bécane.
Tes deux dernières phrases entrent en conflit. D'une part, un programme ne peut avoir besoin que de libX11.so.6. D'autre part, si le programme dépend de libX11.so.6, libc.so.6, libm.so.6, tu vois trivialement dans le package qui fournit libX11.so.6, qu'il dépend également de libc.so.6, donc la dépendence sur libc.so.6 pour le programme d'origine, n'empêche nullement l'installation sur une autre bécane. De plus, un programme ne peut dépendre de libX11.so tout court, vu que libX11.so est le linkname, et ce qu'il y a dans les entrées DT_NEEDED du programme ce sont les libs qui ont des SONAMEs idoines.
Avec Mandrake au-lieu d'avoir un simple "Requires: libtoto.so.0" (fait automatiquement) il y a aussi "Requires: libtoto0".
Précise pour quel package car il ne doit plus en rester telles que "Requires: libtoto0", sauf s'il faut une dépendence explicite sur une certaine libtoto0. e.g. Requires: %{libtoto} = version-release, ou %{libtoto} >= version (plus rare mais là on c'est qu'on est sûr que c'est binary compatible depuis cette version).
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par Gwenole Beauchesne . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 4.
Qui ne marche pas correctement. Si le package n'est pas correctement libifié, tu peux avoir des conflits par exemple juste à cause des %doc. De même, rpm ne gérait des installs de packages biarch que s'ils avaient la même version-release exactement. Par ailleurs, quand ensuite tu veux *mettre à jour* l'un des packages ben tu étais couillonné: l'autre instance disparaissait de la base rpm.
Au fait, j'indique au passage que la version officielle de rpm 4.2.2 n'est pas triviale à trouver, i.e. ce n'est pas celle de rpm.org. De même le développement de rpm 4.2 est postérieur au début du développement de Mandrakelinux pour amd64 (vers mai 2002). Donc, il fallait une solution simple et triviale à gérer pour maximiser la flexibilité. Par exemple, si je voulais une nouvelle ABI 32-bit, les packages de lib correspondant s'appelleraient lib32bidule.
Par ailleurs, il est intéressant de noter que même RedHat commence à libifier un peu ses packages de sorte à limiter les conflits possible lors d'installation de packages ia32/amd64 en parallèle.
Sous Mandrakelinux, tu peux installer n'importe quel lot de packages libifiés sans aucun conflit et qui peuvent être mis à jour indépendamment, l'un de l'autre. C'est pratique quand tu veux un package ia32 qui dépend d'une lib plus récente ou plus ancienne, qui n'existe pas parallèlement en natif.
[^] # Re: Optimisation maximale de Gentoo
Posté par Gwenole Beauchesne . En réponse à la dépêche Optimisation maximale de Gentoo. Évalué à 1.