> Ces trucs là ne sont pas fait sous RedHat/Fedora.
C'est pour supporter d'avoir des bibliothéques 64 bits et 32 bits lors du lancement des applications.
Grossomodo, pour pouvoir faire des installations cote à cote de softs IA32, et de softs IA64, sur amd64, il faut supporter les installations cote à cote des libs, sinon, tu as un conflit. Par exemple, konqueror en ia32 a besoin de libplop3, donc il faut libplop3-3.2-1mdk instaallé, mais en même temps, ton openoffice 64 bits a aussi besoin de libplop3, mais en 64 bits.
Pour pouvoir avoir la version 64 bits et la 32 bits, il faut les avoir nommés différement, sinon les rpms entre en conflits, au niveau des noms et au niveau des fichiers
Par exemple, sur amd64, nous avons : lib64png3, et lib lib64png3-devel.
Le prefixe est décidé par une macro, appelé %mklibname, comme tu as du le voir en lisant le howto ou en examinant les documents.
Pour ceux qui n'ont pas lu le howto, je rappelle son fonctionnement :
Elle renvoie lib sur ia32 et lib64 sur ia64 ( enfin, je réduit, ça marche aussi sur sparc et sparc64 ).
De même, la macro %_libdir permet de distinguer les fichiers.
La ou ça pose problème, c'est que un paquet doit avoir une dépendance de compilation qui soit la même quelque soit la plateforme. On ne peut pas mettre
BuildRequires : libplop3-devel, car on ne compile plus sur archi 64 bits.
Et on ne peut pas mettre lib64plop3-devel, pour des raisons évidentes.
Il a donc été décidé de rajouter des provides indépendant de la plateforme sous jacente, qui sont les 2 points que tu as soulevés.
Pourquoi 2 ?
libplop-devel n'est pas versionné, mais on peut trés bien ajouté plop3-devel pour rajouter une version au provides à la place d'utiliser libplop3-devel, car ce dernier, comme expliqué avant, n'est pas valide sur amd64.
Voila pourquoi il y a 2 provides en plus, ainsi que divers tests rpmlint pour vérifier ça.
Des provides qui ne change rien de spécial par eux mêmes, contrairement à ce que tu veut laisser sous entendre, pour fudder.
Fedora/RH ne le fait pas, car de toute évidence, avoir ce genre de système ne les intéressent pas, car ils est certains que tout le monde va passer direct au 64 bits, d'un seul coup.
[^] # Re: Mandrakelinux 10.0 Official est arrivée !
Posté par Misc (site web personnel) . En réponse à la dépêche Mandrakelinux 10.0 Official est arrivée !. Évalué à 4.
C'est pour supporter d'avoir des bibliothéques 64 bits et 32 bits lors du lancement des applications.
Grossomodo, pour pouvoir faire des installations cote à cote de softs IA32, et de softs IA64, sur amd64, il faut supporter les installations cote à cote des libs, sinon, tu as un conflit. Par exemple, konqueror en ia32 a besoin de libplop3, donc il faut libplop3-3.2-1mdk instaallé, mais en même temps, ton openoffice 64 bits a aussi besoin de libplop3, mais en 64 bits.
Pour pouvoir avoir la version 64 bits et la 32 bits, il faut les avoir nommés différement, sinon les rpms entre en conflits, au niveau des noms et au niveau des fichiers
Par exemple, sur amd64, nous avons : lib64png3, et lib lib64png3-devel.
Le prefixe est décidé par une macro, appelé %mklibname, comme tu as du le voir en lisant le howto ou en examinant les documents.
Pour ceux qui n'ont pas lu le howto, je rappelle son fonctionnement :
Elle renvoie lib sur ia32 et lib64 sur ia64 ( enfin, je réduit, ça marche aussi sur sparc et sparc64 ).
De même, la macro %_libdir permet de distinguer les fichiers.
La ou ça pose problème, c'est que un paquet doit avoir une dépendance de compilation qui soit la même quelque soit la plateforme. On ne peut pas mettre
BuildRequires : libplop3-devel, car on ne compile plus sur archi 64 bits.
Et on ne peut pas mettre lib64plop3-devel, pour des raisons évidentes.
Il a donc été décidé de rajouter des provides indépendant de la plateforme sous jacente, qui sont les 2 points que tu as soulevés.
Pourquoi 2 ?
libplop-devel n'est pas versionné, mais on peut trés bien ajouté plop3-devel pour rajouter une version au provides à la place d'utiliser libplop3-devel, car ce dernier, comme expliqué avant, n'est pas valide sur amd64.
Voila pourquoi il y a 2 provides en plus, ainsi que divers tests rpmlint pour vérifier ça.
Des provides qui ne change rien de spécial par eux mêmes, contrairement à ce que tu veut laisser sous entendre, pour fudder.
Fedora/RH ne le fait pas, car de toute évidence, avoir ce genre de système ne les intéressent pas, car ils est certains que tout le monde va passer direct au 64 bits, d'un seul coup.