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