> - dépendances plus nombreuses (dépendances conseillées, suggérées...)
Ce qui n'a rien de difficile à gérer. C'est au développeur du paquet d'ajouter l'info, c'est aux programmes utilisateurs de lire l'info et de l'afficher. Bref, pour le gestionnaire de paquet il n'y a rien à faire (juste prévoir de la place pour stocker l'information).
> et l'utilisation de rpm est en chute libre...
Évidement, tu n'as aucun chiffre pour appuyer ça. T'as fait une remarque qu'on pouvait lire il y a plusieurs années. C'est dire si ce n'est pas pertinent pour un sou.
Pour ton info, car j'ai l'impression que c'est confus dans ta tête :
yum => utilise rpm
apt4rpm => utilise rpm
urpmi => utilise rpm
> - sensiblement plus rapide
Oui. Mais aussi car rpm est plus "subtil". Par exemple glibc-2.3.3 ne fornit pas que glibc 2.3.3. Mais :
GLIBC_2.0 (exemple : libnss_dns.so.1(GLIBC_2.0), libpthread.so.0(GLIBC_2.0))
GLIBC_2.1
GLIBC_2.1.1
GLIBC_2.1.2
GLIBC_2.1.3
GLIBC_2.2
GLIBC_2.2.1
GLIBC_2.2.2
GLIBC_2.2.3
GLIBC_2.2.4
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
Celà est détecté automatiquement. Si t'as un programme qui a besoin de GLIBC_2.0, pas de problèmes. Les Requires sont aussi fait automatiquement. Pas de risque d'oublier un "Requires glibc > 2.3.1".
> Perso je considère que ton exemple montre un défaut du paquet ppp (pppoatm) plutôt qu'un défaut de dpkg
Avec rpm, tu n'as rien à faire pour que ces dépences soient détectées. Avec dpkg, il faut le faire à la main. Peut-être pas un défaut de dpkg mais c'est une faiblesse par rapport à rpm (qui a ça depuis.... fort fort longtemps).
> Heu, dpkg n'a pas à le supporter : tous les paquets sont dispos pour les deux à la fois ou presque...
N'as pas à le supporté car Debian ne propose pas de distribution amd64 qui permet d'avoir des programmes i386. Actuellement il n'y a pas openoffice pour amd64 par exemple.
Ben avec rpm, tu as un système amd64 + openoffice en i386 (car ça n'existe pas en amd64) avec ces dépendance en i386. A côté de ça, tu as aussi les lib amd64 pour les programmes en amd64.
T'es content d'un système qui ne gère pas prelink, qui ne gère pas automatiquement les versions d'api, qui ne fait pas de détection require/provide automatique, ne propose pas de distribution amd64, etc...
Mieux, tu trouves ça bien...
Apparament, t'y comprend rien en gestionnaire de paquets.
[^] # Re: Ha redhat
Posté par 007 . En réponse au message Débutant en mank d'information. Évalué à 0.
Ce qui n'a rien de difficile à gérer. C'est au développeur du paquet d'ajouter l'info, c'est aux programmes utilisateurs de lire l'info et de l'afficher. Bref, pour le gestionnaire de paquet il n'y a rien à faire (juste prévoir de la place pour stocker l'information).
> et l'utilisation de rpm est en chute libre...
Évidement, tu n'as aucun chiffre pour appuyer ça. T'as fait une remarque qu'on pouvait lire il y a plusieurs années. C'est dire si ce n'est pas pertinent pour un sou.
Pour ton info, car j'ai l'impression que c'est confus dans ta tête :
yum => utilise rpm
apt4rpm => utilise rpm
urpmi => utilise rpm
> - sensiblement plus rapide
Oui. Mais aussi car rpm est plus "subtil". Par exemple glibc-2.3.3 ne fornit pas que glibc 2.3.3. Mais :
GLIBC_2.0 (exemple : libnss_dns.so.1(GLIBC_2.0), libpthread.so.0(GLIBC_2.0))
GLIBC_2.1
GLIBC_2.1.1
GLIBC_2.1.2
GLIBC_2.1.3
GLIBC_2.2
GLIBC_2.2.1
GLIBC_2.2.2
GLIBC_2.2.3
GLIBC_2.2.4
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
Celà est détecté automatiquement. Si t'as un programme qui a besoin de GLIBC_2.0, pas de problèmes. Les Requires sont aussi fait automatiquement. Pas de risque d'oublier un "Requires glibc > 2.3.1".
> Perso je considère que ton exemple montre un défaut du paquet ppp (pppoatm) plutôt qu'un défaut de dpkg
Avec rpm, tu n'as rien à faire pour que ces dépences soient détectées. Avec dpkg, il faut le faire à la main. Peut-être pas un défaut de dpkg mais c'est une faiblesse par rapport à rpm (qui a ça depuis.... fort fort longtemps).
> Heu, dpkg n'a pas à le supporter : tous les paquets sont dispos pour les deux à la fois ou presque...
N'as pas à le supporté car Debian ne propose pas de distribution amd64 qui permet d'avoir des programmes i386. Actuellement il n'y a pas openoffice pour amd64 par exemple.
Ben avec rpm, tu as un système amd64 + openoffice en i386 (car ça n'existe pas en amd64) avec ces dépendance en i386. A côté de ça, tu as aussi les lib amd64 pour les programmes en amd64.
T'es content d'un système qui ne gère pas prelink, qui ne gère pas automatiquement les versions d'api, qui ne fait pas de détection require/provide automatique, ne propose pas de distribution amd64, etc...
Mieux, tu trouves ça bien...
Apparament, t'y comprend rien en gestionnaire de paquets.