@yohann : la recuperation de la liste des paquets dispo est tributaire de la vitesse des serveurs,
non pas de la gui qui mise a part demander plus de ressource pour mettre a jours les widjets n'intervient pas sur le telechargement.elle ne devient un poid qu'au moment de la resolution des dependances qui demande deja a elle seule beaucoup de ressource.donc changer le moteur de dependance pour un plus rapide(moin de temp processeur) ameliore l'ensemble des performances de l'outil graphique.
dans ton idée c'est sutout les depots qu'il faudrait former differrament.splitter la liste en plusieur morceau et un petit fichier qui tiendrait compte des changements des ces morceaux.

@pingoomax :
pas tout a fait non plus yumex est basé sur la lib de yum mais ne se contente pas d'executer des batchs

@yohann : ca me parrais tres lourd comme fonctionnement,il doit y avoir des solutions plus simples. synaptic doit utiliser un autre system : faudrait jetter un coup d'oeil

En effet, c'est un peu lourd (au niveau archi et infrastructure à mettre en place). Une meilleure solution à terme serait effectivement une réorganisation des dépôts à la base comme tu le suggère :

ded wrote:c'est surtout les dépôts qu'il faudrait former différemment. splitter la liste en plusieurs morceau et un petit fichier qui tiendrait compte des changements des ces morceaux.

Et bien sûr, c'est une bonne chose d'améliorer l'algo de gestion des dépendances, mais c'est un autre problème de perf.

Bonjour,
On ne parle pas de smart ni de smart-gui, je l'utilise, il est plus rapide que yum et gère bien les dépendances. Mais je ne suis pas suffisamment compétent pour comparer ces deux outils, aussi, pourrais-je avoir quelques précisions sur l'intérêt de l'un ou de l'autre ?
cymru

Smart et son interface graphique relève du même champ fonctionnel général que Yum-Ymex (ou autres environnements graphiques) : ils sont tous deux des gestionnaires de dépendances avancés (ils permettent d'installer, supprimer, mettre à jour des paquetages en résolvant toutes les dépendances à l'aide de dépôts).

Smart et Smart-gui présentent cependant quelques avantages significatifs:

1- ils savent très correctement gérer les retours arrière (revenir à une version précédente d'un rpm en traitant toutes les dépendances avancées) et permettent ainsi de régler quelques douloureux cas liés à des mélanges de dépôts ...
2- les téléchargements sont réalisés en parallèle; en d'autres termes, quand plusieurs dépôts sont attaqués, les téléchargements sont parallélisés en sorte que le blocage d'un dépôt n'entraîne pas le blocage complet (ce qui est le cas de Yum);
3- ils disposent de fonctionnalités de traitement des anomalies (ils permettent de détecter les rpm pour lesquels des dépendances ne peuvent être réglées par exemple ... et fixent certaines petites anomalies);
4- ils supportent sans aucun préalable des dépôts locaux (sur disque dur par exemple), au contraire de Yum qui réclame un utilitaire particulier (createrepo) et demande que cet utilitaire soit passé systématiquement à chaque modification du dépôt local; à noter aussi qu'ils supportent tous les supports amovibles possibles;
5- ils gèrent différents formats de dépôts (le format de dépôt de Yum, soit MetaData rpm, mais aussi d'autres formats dont URPMI, apt etc ....); dès lors Smart - Smart-gui sont des outils 'multi canaux'.

Je ne discute pas là l'interface graphique; à ce titre, je suggère que Smart-gui est bien supérieur à Yumex en permettant une description profonde et simple des différentes dépendances d'un paquetage (dépendances amont et dépendances aval) mais ce dernier thème va sans doute susciter du blabla alors que l'essentiel n'est pas là mais dans les 5 points précédents ...


On l'aura compris, je suis un utilisateur fidèle de Smart. Certains diront que les performances de Smart ne sont pas celles d'apt ou de yum mais de très fondé n'est avancé et il convient de relativiser le propos en tenant compte des fonctionnalités apportées:

* le téléchargement en parallèle amène des gains significatifs (pourvu que la liaison soit de bonne capacité)
* la constitution d'une méta représentation des différents paquetages, systématique à chaque mise à jour, consomme effectivement du temps mais elle est la contre partie de la volonté de Smart de gérer plusieurs formats de dépôts dont le fameux dépôt local (un répertoire de rpm par exemple ...), ce que Yum ne sait pas faire.

Je ne doute pas que la question des performances soit aussi un sujet de blabla, alors que l'essentiel n'est pas vraiment là.

Merci herrib, toujours aussi clair, net, précis et concis.
cymru

pour smart tout a fait daccord c'est un super outil, smart-gui par contre m'agace: tout le temp en train de mettre a jour le cache,de l'enregister ce qui bloque l'utilisateur
moi qui préfere les gui en general, j'ai adopté la cli pour smart et yum

Effectivement, Smart est une alternative plus que crédible à Yum pour l'utilisateur mais pas pour le projet Fedora. Fedora a besoin d'un gestionnaire de dépendances fortement intégré à la distribution que ce soit dans l'installeur, le système de build, l'outils de génération d'images isos .... etc bref, ce que ne permet pas Smart.
Après, depuis que apt4rpm, smart et yum reconnaissent le même format de dépôt, ce n'est plus vraiment un souci, les utilisateurs peuvent utiliser ce qu'ils veulent, c'est leur droit.
PS: Yum gère désormais les downgrades via un plugin ...

Sat wrote:PS: Yum gère désormais les downgrades via un plugin ...

...et aussi le « traitement des anomalies » décrites par herrib : voir le plugin yum-skip-broken 😉

MrTom wrote:

baptistoux wrote: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.

Vraiment parfois on touche le fond.
Tu devrais installer toutes les Fedora depuis le début, une part une et dans l'ordre, et te rendre compte à quel yum s'est amélioré de version en version.

Je pense que tu a mal interprété mes propos,
Je n'ai pas dit que yum ne s'était pas amélioré depuis son introduction (si si, je suis passé par toutes les FC, sauf la 3, et avant par les RH depuis la V7.3, donc mon "amour" pour cette distrib ne date pas d'hier), mais je persiste à dire que apt/dpkg, pour ne pas le nommer, et plus rapide, surtout pour le calcul des dépendances. Dire cela n'est pas dénigrer Fedora, c'est juste avouer une faiblesse récurrente de la distrib (et je ne pense pas être le seul a le penser, surtout pour ceux qui viennent du "monde" Debian).
Alors, avant de me dire que je touche le fond, je pense que tu devrais te renseigner.

Bonne journée.

Mais passer son temps à faire des comparaisons Fedora / Debian en disant que le gestionnaire de paquets de l'une est plus/moins rapide que l'autre, n'a pas de sens. On rerpproche très souvent à YUM de charger la liste des serveurs à chaque fois qu'il est invoqué, alors que c'est tout à fait cohérent au regard de l'objectif de la distribution : aller vite. C'est une obsession du Projet Fedora de "pousser tout le monde au cul" pour aller de l'avant. Fedora le dit également haut et fort, nous sommes censés avoir toujours les dernieres versions des logiciels disponibles. Dès lors, ces deux ojectifs annoncent clairement les choses : les dépôts vont être souvent modifiés. Il est donc normal que YUM rafraichisse automatiquement ses serveurs.
Et les objectifs de Debian et d'Ubuntu son complètement différents. Debian cherche la stabilité à tout pris, Ubuntu cible le très grand public. Sur cette dernière, seules les mises à jour de sécurité sont admises et il est très rare de voir une nouvelle version de logiciel entrer dans le dépôt au cours d'un cycle de release. Dès lors, il n'y a pas besoin de rafraichir la liste des dépôts à tout bout de champ.

Alors je pense que les critiques, sur la rapidité de YUM et la façon dont il fonctionne n'ont pas lieu d'être.
Pour la forme, oui, parfois à lire des choses, je bous, je m'emporte je fulmine ! Et je deviens cassant 🙁 Toutes mes confuses cher ami !

Mr Tom toute fois on pourait considerai que rafraichir la liste des depots une fois par jour hors demande particuliere de l'utilisateur serait acceptable.
cela accelerer yum et diminurait la charge des depots.et ca serait meme le moment d'avertir l'utilisateur des maj disponible pour le "poussé au cul"

Je te conseil alors de modifier ton fichier /etc/yum.conf en conséquence :

metadata_expire=86400

tiens je vais regarder un peu se qui est configurable dans ce yum.cof j'y avais pas pensé :-s

man yum.conf
On a la chance avec yum d'avoir des pages du manuel à jour, profites-en !