> càd qu'il gère l'héritage des dépandances? Merveilleux.
> Ou alors il analyse le binaire pour déterminer quelles libs sont nécessaires... pas tellement utile non plus.
C'est utile. C'est la librairie avec son numéro de version qui définie la compatibilité et pas autre chose. Sinon c'est de la duplication d'info. En fesant ainsi, tu peux remmoner des paquets les fusionner, etc... Tout ce qui compte, c'est la facilité réellement fournie et non le nom du paquet. L'héritage est aussi utile car il permet de limiter les nombres de dépendances et ne pas tomber dans l'ingérable. Rpm peut aussi définir des dépendances virtuels (style require: kde) ou des dépendances sur des fichiers ou sur une configuration. Par exemple lors d'un passage de ppp à ppp_ng si ppp_ng utilise config(ppp > 2) qui est déjà fourni par ppp-2.5 et que tu mets à jours, tes fichiers de configuration seront conservés. En fait le système de génération des dépendances utilise des plugins et rien ne t'empêche de devopper de nouveaux plugins (par exemple sur les symboles fournis par le noyau pour vérifier si un module noyau peut-être installé et marchera). Il y a quelques mois un plugins pour gérer les dépendances perl a été ajouté. Il y a un plugin pour prelink, ainsi rpm peut vérifier un binaires même s'il a été modifié par prelink.
rpm gère aussi les branches de paquets. T'as un gnome-2.2.2 spécifique qui utilise un libgnome-2.2.2 spécifique incompatible avec la branche 2.2, si un gnome-2.2.3 "standard" sort, il n'écrasera pas ta version spécifique mais un gnome-2.2.3 avec tes spécificités (marqués par le tag Epoch) sera un candidat pour la mise à jours.
rpm gére aussi les mises à jours sur plusieurs paquets et non seulement sur un seul. C'est l'ensemble des paquets qui sera évalué pour une mise à jour ou une installation et ce n'est pas fait paquet par paquet. un "rpm -U ppp_ng" pourra remplacer ppp et pppoe. Un "rpm -U ppp_ng pppoe" peut être utilisé pour mettre à jour le paquet ppp alors qu'un "rpm -U ppp_ng" n'est pas suffisant. Rpm gère les paquets absolètes. Rpm offrira dans 1 ou 2 mois la possibilité d'annulé la dernière transaction d'installation/mise à jours (c'est un transaction car rpm fait l'opération sur plusieurs paquets qui forme un tout).
> Les SLOTs (aka possibilité de considérer plusieurs version d'un même soft comme étant des logiciels diffèrents à installer en paralèle (QT, GTK...)).
Comme rpm. S'installation en parallàle ne pause pas de problème. Du moins lorsqu'elle est prévus. C'est une pratique très courrante.
> Et pis, franchement, quand on "crois" juste; vaut mieux ne rien dire, surtout quand le sujet est trollogène.
[^] # Re: Test de la Gentoo 1.4
Posté par Austin . En réponse à la dépêche Test de la Gentoo 1.4. Évalué à 1.
> Ou alors il analyse le binaire pour déterminer quelles libs sont nécessaires... pas tellement utile non plus.
C'est utile. C'est la librairie avec son numéro de version qui définie la compatibilité et pas autre chose. Sinon c'est de la duplication d'info. En fesant ainsi, tu peux remmoner des paquets les fusionner, etc... Tout ce qui compte, c'est la facilité réellement fournie et non le nom du paquet. L'héritage est aussi utile car il permet de limiter les nombres de dépendances et ne pas tomber dans l'ingérable. Rpm peut aussi définir des dépendances virtuels (style require: kde) ou des dépendances sur des fichiers ou sur une configuration. Par exemple lors d'un passage de ppp à ppp_ng si ppp_ng utilise config(ppp > 2) qui est déjà fourni par ppp-2.5 et que tu mets à jours, tes fichiers de configuration seront conservés. En fait le système de génération des dépendances utilise des plugins et rien ne t'empêche de devopper de nouveaux plugins (par exemple sur les symboles fournis par le noyau pour vérifier si un module noyau peut-être installé et marchera). Il y a quelques mois un plugins pour gérer les dépendances perl a été ajouté. Il y a un plugin pour prelink, ainsi rpm peut vérifier un binaires même s'il a été modifié par prelink.
rpm gère aussi les branches de paquets. T'as un gnome-2.2.2 spécifique qui utilise un libgnome-2.2.2 spécifique incompatible avec la branche 2.2, si un gnome-2.2.3 "standard" sort, il n'écrasera pas ta version spécifique mais un gnome-2.2.3 avec tes spécificités (marqués par le tag Epoch) sera un candidat pour la mise à jours.
rpm gére aussi les mises à jours sur plusieurs paquets et non seulement sur un seul. C'est l'ensemble des paquets qui sera évalué pour une mise à jour ou une installation et ce n'est pas fait paquet par paquet. un "rpm -U ppp_ng" pourra remplacer ppp et pppoe. Un "rpm -U ppp_ng pppoe" peut être utilisé pour mettre à jour le paquet ppp alors qu'un "rpm -U ppp_ng" n'est pas suffisant. Rpm gère les paquets absolètes. Rpm offrira dans 1 ou 2 mois la possibilité d'annulé la dernière transaction d'installation/mise à jours (c'est un transaction car rpm fait l'opération sur plusieurs paquets qui forme un tout).
> Les SLOTs (aka possibilité de considérer plusieurs version d'un même soft comme étant des logiciels diffèrents à installer en paralèle (QT, GTK...)).
Comme rpm. S'installation en parallàle ne pause pas de problème. Du moins lorsqu'elle est prévus. C'est une pratique très courrante.
> Et pis, franchement, quand on "crois" juste; vaut mieux ne rien dire, surtout quand le sujet est trollogène.
J'en suis sûre.