Voilà une bonne nouvelle, les mises à jour sous F7 se feront plus rapidement, et dans de meilleures conditions.

pourquoi avoir choisit python? c'est pas le plus rapide !

heu....désolé mais mon anglais n'est pas parfait...et je ne suis pas sûr de tout comprendre...Ils comptent supprimer YUM?? si ce n'est pas ça est-ce que quelqu'un pourrait faire un rapide résumé en français svp?? merci d'avance

Il était temps qu'il s'occupe un peu d'accelerer 'yum', car ça lenteur par rapport a d'autres outils du meme types sur d'autre distrib est une critique récurrente.

Bonne nouvelle, ca promet de bonne chose pour la suite.

Le retour de l'Arlésienne, depuis un ou deux ans, yum est plus rapide que apt4rpm, c'est pas moi qui l'a inventé, c'est le mainteneur actuel de apt4rpm qui est également un des développeurs de yum.
Depuis qu'ils ont réécrit le parseur de metadata en C et que yum ne charge plus systèmatiquement les metadata, yum est nettement plus véloce au point que la différence avec apt/dpkg est à peine visible.
Quant au langage utilisé, il a peu d'incidence pour un gestionnaire de dépendances, Python a quelques lacunes comme sa gestion complétement naze des chaines qui a justifié en partie la réécriture en C du parseur de métadata. Néanmoins, c'est un langage de haut-niveau, connu des développeurs Fedora, extrêmement souple (écrire un plugin pour yum est un jeu d'enfant comparé à l'écriture d'un plugin pour apt), qui s'interface très bien avec le C pour les parties critiques.
Puis, hein, développez un gestionnaire de dépendances tel que yum en C ou en C++, ça aurait pris beaucoup plus de temps, et les perfs n'auraient pas forcément au rendez-vous car un programme passe 80% du temps dans 20% du code. Ce qui importe c'est d'optimiser les parties critiques, et là c'est la gestion des dépendances à travers la rpmlib.

Le point noir de yum c'est la gestion des dépendances, et vu la complexité de l'algorithme, tu as plus de chances de l'optimiser en améliorant l'algorithme qu'en réécrivant tout en C ou en C++. Parce qu'optimiser du C++, c'est pas à la portée de tout le monde.
Tu m'as mal compris, je ne dis pas que le code est enfermé dans la même boucle mais que seul une petite partie du code est exécuté la plupart du temps, si tu optimise les parties critiques, ton programme sera sensiblement plus véloce. En optimisant les parties non critiques, tes gains seront minimes voire inexistant.

Le C ou le C++ ne rendra pas ton code intrinsèquement plus rapide,

Quand je parle de apt/dpkg , c'est le apt utilisé dans Debian, Ubuntu ... dans la plupart des cas, la différence de performances entre yum et apt/dpkg n'est pas visible pour l'utilisateur sauf quelques cas ou les dépendances sont hard à gérer.

Ça serait bien d'intégré le classement par date d'entrée et de mise à jours des paquets! je pense que ça ne doit être bien compliqué à faire!

D'intégrer dans quoi? dans le gestionnaire de dépendances avancées? Les interfaces graphiques fournissent quelques éléments... Cependant:

# rpm -q --qf "%{NAME}\t%{INSTALLTIME:date}\n" nom_du_paquetage
# rpm -q --qf "%{NAME}\t%{BUILDTIME:date}\n" nom_du_paquetage
rpm -q --last liste_de_paquetage

=> date d'installation du paquetage
=> date de construction du paquetage
=> interrogation des paquetages installés et classement par date d'installation

@remi : quel base de donnée? yum utilise un fichier xml present sur le depot !(non?)
@Sat : quand je suis arrivé de kubuntu(oui je sais mais y a un debut a tout) la premiere chose que je me suis dit c'est : "oula c'est lent leur yum"
et c'est pas une question de 1 seconde quand tu as tout tes softs a installer.
mais je reconnais que pour optimiser l'algorithmique python est plus pratique.

pour faire une update vide 13 secondes ... c'est pire ! ca serait pas possible de juste verifier si les xml ont été modifiés?(je suis surement a coté de la plaque mais au moin j'apprendrais quelque chose!)

dans les outils graphique! style yumex!

Mon avis perso sur les perf, ben il est plutot négatif à la vue de ce papier.
En tout cas par rapport au temps d'execution (3eme tableau)
Les grosses maj sont améliorées très significativement, pas contre les petites (au final, celles de tous les jours) sont plutot en baisse.

En tout cas, à plus long terme, il semble que la réécriture du moteur de traitement des dépendances soit prometeuse.

Pour ceux qui ne parlerait pas du tout anglais, l'auteur compare trois versions de yum :
- celle présente dans FC6 (yum 3.0.3) (1ere colonne des tableaux)
- celle de la branche devel - ie celle qui sera présente (à peu pres) dans F7 (2eme colonne)
- et une version qui n'utilise plus rpm mais une reécriture complete (pyrpmyum) qui est en test en ce moment et qu'ils espèrent intégrer dans F8 (Colonne 3)

Plusieurs tests sont fait :
INSTALL
- installation normale (856 paquets)
- installation complete (6057 paquets) - ce qui implique beaucoup d'exclusion de paquets pour résoudre toutes les dépendances
- Grosse installation "[a-k]*" (3052 paquets en comptant les dependances)
UPDATE
- tentative de maj sans maj disponible
- Grosse update
- Dist upgrade (mise à jour de FC5 à FC6)
SUPPRESSION
- suppression de glibc (828 paquets)

Ceci selon 3 criteres dévaluation
- maximum de mémoire allouée (1er tableau)
- total de memoire allouée (2eme tableau)
- temps d'exécution en secondes (3eme tableau)

Voilà, tout devrait etre clair maintenant.

Je me suis dit la même chose que pingoomax 😉

(par contre moi, la patience ... je l'ai apprise hein ... source oblige ^^)

Un changement de bibliothèque ne va pas accélérer un outil graphique comme Yumex de manière impressionnante…
Pour un outil graphique comme Yumex, la lenteur se fait surtout sentir lors de la mise à jour de la liste des paquets dispos pour chaque dépôt.
Il y a sans doute une meilleure solution que celle qui consiste à rapatrier la liste complète des paquets puis de mettre à jour la base de donnée des paquets disponibles, installés et à mettre à jour.
Je pense qu'il ne devrait pas être nécessaire de rapatrier la liste complète (des milliers de descriptions de paquets) à chaque fois).
Une bonne solution, à mon avis, serait de pouvoir récupérer rapidement d'une manière ou d'une autre, la liste des paquets proposant une mise à jour ou ajoutés depuis le dernier démarrage de Yumex (depuis une date donnée). Ainsi, si on rapatrie uniquement ce qui est nouveau depuis le dernier lancement de l'application et pas 10000 descriptions de paquets.

Yumex n'est qu'une interface graphique qui appelle yum.
Donc améliorer yumex se limite à améliorer l'interface.

Ton idée de mise à jour différentielle est déjà en cours de développement.
Enfin c'est un truc plus compliqué que ce dont tu parles.
Cf : https://hosted.fedoraproject.org/projects/presto