> Par exemple, "rpm-libs" est apparu avec rpm 4.2.3.
Et alors ?
> Je parle de rpm, c'est pourtant marqué en clair dans les commentaires, et très lisible dans les sources.
T'es gentil mais t'as vue la taille des sources de rpm ? Je ne crois pas.
Donnes au moins le nom fichier puisque c'est si évident pour toi.
> En cas de conflit, et vu que tu spécifies les 2 packages sur la même ligne de commande, rpm ignorera les conflits et installera les binaires elf64 qu'il trouve.
Non. En cas de comflit, rpm s'arrête. rpm est un outils bas niveau et pas "smart".
Puisque tu connais à fond les sources de rpm, tu dois bien pouvoir me dire où rpm fait fait :-)
> Pourvu que tu n'aies pas de /usr/share/doc/ par exemple qui diffère d'un chouia. Avec une approche où le package de libs s'appelle différemment, tu ne peux pas avoir de conflit pour les docs par exemple.
C'est là la grande nouveauté ?
Formidable. Pour libglib-devel (de mandriva), il y a en commun :
/usr/bin
/usr/include/glib-2.0
/usr/share/aclocal
/usr/share/gtk-doc
/usr/share/man
Pour libglib :
/etc/profile.d
/usr/share/locale
Alors ton "/usr/share/doc" me fait bien rire alors qu'il suffit qu'un fichier .mo ou la doc dans /usr/share/gtk-doc de modifié pour foutre le bordel. C'est comme ça dans Mandriva !
> ça peut être une version-release différente
Mandrake a le même problème (sauf pour /usr/share/doc ; super !).
> Deuxième chose, installer c'est bien, pouvoir mettre à jour c'est mieux. Et là, le système de résolution de conflits implicite est moins flexible.
Même problème pour Mandriva puisqu'il y a des fichiers en commun.
> D'autre part, dans le cas de glib2.0-devel, les conflits sont ignorés car les binaires glib-genmarshal et gobject-query sont marqués elf64 donc préférés à l'install. i.e. si tu installes la version 32-bit après la 64-bit, l'ancien binaire 64-bit est conservé.
Non. Ça n'a tout simplement pas de sens de faire ça.
Exemple :
- tu as la version i386
- tu ajoute la version amd64 (qui écrase la version i386)
- tu retire la version amd64
=> il se passe quoi ?
De plus pour glib, ça n'a pas de sens. Les programmes dans /usr/bin/ sont spécifiques, donnent des données spécifiques (différent pour i386 et x86_64).
> J'ai dit "glib-devel"
Il n'y a pas de paquet glib-devel dans Mandriva LE 2005 !
> tu regardes correctement et tu réalises que c'est glib 1.2.
De quoi tu parles ?
J'ai seulement regarder glib 2.0.
> Par ailleurs, je n'aime pas trop ce système de résolution implicite des conflits rpm à préférer par défaut les binaires 64-bit sans warning.
rpm ne le fait pas. Trouves moi le code de rpm si c'est si simple.
> De fait, tu as par exemple /usr/bin/multiarch-i386-linux/glib-config et /usr/bin/multiarch-x86_64-linux/glib-config.
Ce n'est pas suffisant. Vraiment pas.
> Au final, tu peux rebuilder des packages 32-bit aussi simplement que linux32 rpm --rebuild evolution.rpm (pour avoir du i586.rpm) ou rpm --rebuild evolution.rpm (pour avoir du x86_64.rpm).
Comme Red Hat, mais t'as seulement les *-devel i386 ou amd64 d'installé à la foi. Et c'est idem pour Mandriva !
AUTHOR
Elliot Lee <sopwith@redhat.com>
Jindrich Novy <jnovy@redhat.com>
man setarch :
AUTHOR
Elliot Lee <sopwith@redhat.com>
Jindrich Novy <jnovy@redhat.com>
setarch.c :
/* Copyright (C) 2003 Red Hat, Inc. */
/* Licensed under the terms of the GPL */
/* Written by Elliot Lee <sopwith@redhat.com> */
/* New personality options & code added by Jindrich Novy <jnovy@redhat.com> */
/* ADD_NO_RANDOMIZE flag added by Arjan van de Ven <arjanv@redhat.com> */
/* based on ideas from the ppc32 util by Guy Streeter (2002-01), based on the
sparc32 util by Jakub Jelinek (1998, 1999) */
/* */
[^] # Re: Et le plus important...
Posté par fabb . En réponse au journal Mandriva Linux Limited Edition 2005 released. Évalué à 1.
Et alors ?
> Je parle de rpm, c'est pourtant marqué en clair dans les commentaires, et très lisible dans les sources.
T'es gentil mais t'as vue la taille des sources de rpm ? Je ne crois pas.
Donnes au moins le nom fichier puisque c'est si évident pour toi.
> En cas de conflit, et vu que tu spécifies les 2 packages sur la même ligne de commande, rpm ignorera les conflits et installera les binaires elf64 qu'il trouve.
Non. En cas de comflit, rpm s'arrête. rpm est un outils bas niveau et pas "smart".
Puisque tu connais à fond les sources de rpm, tu dois bien pouvoir me dire où rpm fait fait :-)
> Pourvu que tu n'aies pas de /usr/share/doc/ par exemple qui diffère d'un chouia. Avec une approche où le package de libs s'appelle différemment, tu ne peux pas avoir de conflit pour les docs par exemple.
C'est là la grande nouveauté ?
Formidable. Pour libglib-devel (de mandriva), il y a en commun :
/usr/bin
/usr/include/glib-2.0
/usr/share/aclocal
/usr/share/gtk-doc
/usr/share/man
Pour libglib :
/etc/profile.d
/usr/share/locale
Alors ton "/usr/share/doc" me fait bien rire alors qu'il suffit qu'un fichier .mo ou la doc dans /usr/share/gtk-doc de modifié pour foutre le bordel. C'est comme ça dans Mandriva !
> ça peut être une version-release différente
Mandrake a le même problème (sauf pour /usr/share/doc ; super !).
> Deuxième chose, installer c'est bien, pouvoir mettre à jour c'est mieux. Et là, le système de résolution de conflits implicite est moins flexible.
Même problème pour Mandriva puisqu'il y a des fichiers en commun.
> D'autre part, dans le cas de glib2.0-devel, les conflits sont ignorés car les binaires glib-genmarshal et gobject-query sont marqués elf64 donc préférés à l'install. i.e. si tu installes la version 32-bit après la 64-bit, l'ancien binaire 64-bit est conservé.
Non. Ça n'a tout simplement pas de sens de faire ça.
Exemple :
- tu as la version i386
- tu ajoute la version amd64 (qui écrase la version i386)
- tu retire la version amd64
=> il se passe quoi ?
De plus pour glib, ça n'a pas de sens. Les programmes dans /usr/bin/ sont spécifiques, donnent des données spécifiques (différent pour i386 et x86_64).
> J'ai dit "glib-devel"
Il n'y a pas de paquet glib-devel dans Mandriva LE 2005 !
> tu regardes correctement et tu réalises que c'est glib 1.2.
De quoi tu parles ?
J'ai seulement regarder glib 2.0.
> Par ailleurs, je n'aime pas trop ce système de résolution implicite des conflits rpm à préférer par défaut les binaires 64-bit sans warning.
rpm ne le fait pas. Trouves moi le code de rpm si c'est si simple.
> De fait, tu as par exemple /usr/bin/multiarch-i386-linux/glib-config et /usr/bin/multiarch-x86_64-linux/glib-config.
Ce n'est pas suffisant. Vraiment pas.
> Au final, tu peux rebuilder des packages 32-bit aussi simplement que linux32 rpm --rebuild evolution.rpm (pour avoir du i586.rpm) ou rpm --rebuild evolution.rpm (pour avoir du x86_64.rpm).
Comme Red Hat, mais t'as seulement les *-devel i386 ou amd64 d'installé à la foi. Et c'est idem pour Mandriva !
Ironie :
[admin@one fedora]$ ll -i /usr/bin/linux32 /usr/bin/setarch
83787 -r-xr-xr-x 4 root root 6728 nov 3 20:41 /usr/bin/linux32
83787 -r-xr-xr-x 4 root root 6728 nov 3 20:41 /usr/bin/setarch
man linux32 :
man setarch :
setarch.c :
Mandrake n'a rien inventé.