> De plus, yum peut simuler le comportement de apt en ne téléchargeant pas à chaque fois les metadonnées (Cf man yum, les options makecache et -C).
C'est beaucoup mieux que ça.
S'il n'y a pas "-C", yum vérifie seulement si le dépôt a été mis à jours (downloade d'un petit fichier de 2k). Il downloade plus de 2k que si c'est nécessaire. Il downloade filelists.xml.gz que si c'est nécessaire par exemple (quand une dépendance a par exemple "Require: /usr/bin/toto").
> Aujourd'hui, mon yum n'est pas tellement plus lent que apt/dpkg sur une Ubuntu.
Yum est lent ?
Dans l'absolu non. Relativement à apt et peut-être smart, yum est plus lent.
Mais yum marche superbement. C'est ce qui compte pour moi. Et en passant, rpm roxe aussi.
Juste quelques tests :
[root@trois big_fs]# yum update
fedora 100% |=========================| 2.1 kB 00:00
livna 100% |=========================| 2.1 kB 00:00
updates 100% |=========================| 1.9 kB 00:00
Setting up Update Process
No Packages marked for Update NB: Au-dessus, yum a downloadé que repomd.xml (généralement moins de 2 ko). C'est repomd.xml qui lui indique si le cache est à jour. Ici le cache est à jour, il ne download rien d'autre.
Pour ce cas, si j'avais fait "yum -C update" ça n'aurait économisé que 6 ko ! Mais j'aurais perdu l'assurance d'être synchro avec le dépôt. L'intérêt est donc quasi nulle pour une utilisation classique. Ne pas utiliser "-C" coute peu et est plus fiable (si le dépôt est mise à jours et que ton cache n'est pas synchro avec le dépôt, il y a de grandes chances que ça plante).
real 0m11.170s user 0m6.932s
sys 0m0.864s
[root@trois big_fs]# yum clean all
Cleaning up Everything
[root@trois big_fs]# time yum update
fedora 100% |=========================| 2.1 kB 00:00
primary.sqlite.bz2 100% |=========================| 5.8 MB 00:00
livna 100% |=========================| 2.1 kB 00:00
primary.sqlite.bz2 100% |=========================| 173 kB 00:00
updates 100% |=========================| 1.9 kB 00:00
primary.sqlite.bz2 100% |=========================| 1.8 MB 00:00
Setting up Update Process
No Packages marked for Update
real 0m3.854s user 0m2.904s
sys 0m0.291s Notons bien que "yum update" a moins downloadé que "yum makecache" qui renseigne totalement le cache de yum
[root@trois big_fs]#
C'est largement assez rapide pour moi.
Et notes bien comme Yum pour "yum update" n'a récupéré que le nécessaire pour son boulot.
> Au niveau des mises à jours, c'est non seulement plus rapide et plus économe en bande passante.
Si tu as une bonne bande passante, ce n'est pas plus rapide. Mais dans 99,99 % ça sera plus rapide (et dramatiquement plus rapide lorsque OOo est mise à jours :-)).
Autre aspect, yum-updatesd. yum-updatesd vérifie périodiquement s'il y a des mises à jours. Donc le cache est généralement déjà renseigné lorsque l'utilisateur lance yum ou autre qui utilise yum. La durée du cache est configurable. Option metadata_expire de /etc/yum.conf. Valeur à 1800 (c-à-d 30 minute) par défaut chez Fedora.
Exemple
[root@trois big_fs]# yum clean all
Cleaning up Everything
[root@trois big_fs]# yum update
fedora 100% |=========================| 2.1 kB 00:00
primary.sqlite.bz2 100% |=========================| 5.8 MB 00:00
livna 100% |=========================| 2.1 kB 00:00
primary.sqlite.bz2 100% |=========================| 173 kB 00:00
updates 100% |=========================| 1.9 kB 00:00
primary.sqlite.bz2 100% |=========================| 1.8 MB 00:00
Setting up Update Process
No Packages marked for Update
[root@trois big_fs]# yum update Rien est downloadé
Setting up Update Process
No Packages marked for Update
[root@trois big_fs]#
Au second "yum update", rien est downloadé (le cache est considéré valide car j'ai (paramétrage par défaut de Fedora) "metadata_expire = 1800".
Bref, au-delà de la lenteur relative, yum roxe des ours, yum est particulièrement bien conçu.
PS : deb et apt roxent peut-être aussi (je n'en sais rien). Mais je ne vais pas vomir sur ces derniers car je trouves que rpm et yum roxent.
[^] # Re: Fin du FUD deb/rpm
Posté par IsNotGood . En réponse au journal Mes prédictions pour 2008. Évalué à 1.
C'est beaucoup mieux que ça.
S'il n'y a pas "-C", yum vérifie seulement si le dépôt a été mis à jours (downloade d'un petit fichier de 2k). Il downloade plus de 2k que si c'est nécessaire. Il downloade filelists.xml.gz que si c'est nécessaire par exemple (quand une dépendance a par exemple "Require: /usr/bin/toto").
> Aujourd'hui, mon yum n'est pas tellement plus lent que apt/dpkg sur une Ubuntu.
Yum est lent ?
Dans l'absolu non. Relativement à apt et peut-être smart, yum est plus lent.
Mais yum marche superbement. C'est ce qui compte pour moi. Et en passant, rpm roxe aussi.
Juste quelques tests :
C'est largement assez rapide pour moi.
Et notes bien comme Yum pour "yum update" n'a récupéré que le nécessaire pour son boulot.
> Au niveau des mises à jours, c'est non seulement plus rapide et plus économe en bande passante.
Si tu as une bonne bande passante, ce n'est pas plus rapide. Mais dans 99,99 % ça sera plus rapide (et dramatiquement plus rapide lorsque OOo est mise à jours :-)).
Autre aspect, yum-updatesd. yum-updatesd vérifie périodiquement s'il y a des mises à jours. Donc le cache est généralement déjà renseigné lorsque l'utilisateur lance yum ou autre qui utilise yum. La durée du cache est configurable. Option metadata_expire de /etc/yum.conf. Valeur à 1800 (c-à-d 30 minute) par défaut chez Fedora.
Exemple
Au second "yum update", rien est downloadé (le cache est considéré valide car j'ai (paramétrage par défaut de Fedora) "metadata_expire = 1800".
Bref, au-delà de la lenteur relative, yum roxe des ours, yum est particulièrement bien conçu.
PS : deb et apt roxent peut-être aussi (je n'en sais rien). Mais je ne vais pas vomir sur ces derniers car je trouves que rpm et yum roxent.