@CanalGuada. Tout d'abord, j'en sais probablement moins que toi. Les arguments que j'utilise sont simples, et le but que j'ai n'est pas de tout comprendre, mais de donner une solution simple et rapide à celui qui a un problème, tout en veillant à que cette solution soit générique. C'est à dire que celui qui a le même problème et qui tombe sur ce fil corrige son problème de lui même d'une part, et prend directement la bonne habitude pour les fois suivantes d'autre part...
Dans l'idéal, tout comprendre le pourquoi du comment est la chose vers quoi il faut tendre. Et tu es visiblement bien en avance sur moi, ne serais-ce que par le fait que tu vas mettre le nez là où je n'ai pas le courage de mettre le mien. Cependant pour le problème posé par lemoineo, les connaissances que j'ai suffisent, je pense, pour expliquer à peu près correctement la démarche à suivre pour sa résolution, et le tout de manière générique.
CanalGuada wrote: À l'activation initiale du dépôt, que ce soit par l'une des commandes yum install, yum localinstall, rpm -ivh ou rpm -Uvh mentionnées, aucune commande n'installe la version à jour du paquet nécessaire. Et pour cause... le dépôt n'est consulté à aucun moment pour que ce soit possible.
Oui, je savais ça. J'ai un doute dans le cas du dépot rawhide, mais je ne peu plus vérifier car le branchement a été effectué dans la précédente mise à jour.
Pour obtenir cette mise à jour, il faut soit interroger le dépôt manuellement (via un "yum update" global ou pour le paquet spécifié dans la section <Core> du fichier comps.xml, en ce qui concerne RPMFusion), soit essayer d'installer un paquet quelconque du dépôt.
Moui... Si tu installes via rpm -option, je ne sais pas si le yum update fonctionne, il faudra que j'essai à l'occas'... La partie "comp.xml", j'en sais rien. Et installer un paquet du dépot mettra à jour le dépot ? Ça ne me semble pas évident non plus. Mais soit...
Mais que l'on installe le paquet pour la "version stable" ou le paquet pour la "version rawhide" - qui activeront l'accès au même dépôt pour une même architecture quelle que soit la pre-release F15 et tant que F15 ne sera pas une release officielle - une mise à jour devra se faire si les versions présentes localement et sur le serveur ne correspondent pas, ou plus.
Je ne comprend pas ce que tu dis là... Mais l'idée que les deux paquets fournissent les mêmes dépots à F15 me semble tout à fait plausible.
La seule différence est qu'en installant le paquet pour la "version rawhide" - qui elle contient déjà la clé GPG signant les paquets du dit dépôt - cette mise à jour est plus ou moins transparente et automatique pour l'utilisateur s'il essaie dans la foulée d'installer un paquet quelconque : il peut récupérer en une seule opération celui qu'il désire... sans empêcher que la mise à jour requise pour le dépôt se fasse préalablement.
Ça je ne le comprend qu'à moitié. Ce que je vois, c'est que l'installation de "la version stable" pose des problèmes sur les archis 64 bits de F15. Tu suggères de résoudre le problème par un "yum update" ? Si oui, il n'y a à mon sens pas grand danger à effecteur cette manip, et d'ailleurs dans ce cas, tu aurais du commencer par là, on aurait vite été fixé. Sinon, qu'elle aurait été selon toi la marche à suivre ? Pourquoi ce problème apparait-il uniquement sur les archi 64 bits ? Voici le genre de chose qui me pousse vraiment à croire qu'installer la "version stable" sur F15, n'est pas une bonne chose.
Pour conclure cette petite polémique entre nous et sans aucune animosité, si tu souhaites continuer à apporter la contradiction et alimenter une discussion constructive, je me permet de te suggérer d'avancer des arguments un peu plus documentés et précis, donc intéressants, que ceux vagues ou évidents que tu as utilisés.
Alors, oui encore une fois, techniquement il y a vraisemblablement moyen de s'en sortir en te suivant. Si un "yum update" suffisait à résoudre le problème : OK, je m'incline, mais dans ce cas, pourquoi n'as tu pas commencé par ça??? Par contre, dès le moment où il faut éditer quelques fichier de configurations, etc, la solution ne sera pas considéré comme "là bonne" dans le sens où il est plus sein de laisser les outils mis à disposition faire le travail.
Personne n'a besoin de lire la page man de rpm pour comprendre que la commande n'effectuera probablement pas le même traitement, avec des options différentes... par contre, pour savoir ce qu'elle fera exactement, je ne pense pas être celui qui en a le plus besoin.
Oui, c'est sur, on peut toujours prospecter pour savoir quoi marche comment. Tu peux même aller jusqu'à savoir comment ça marche au niveau hardware : Ok, j'exagère, mais c'est pour illustrer. Seulement, je me contente (à tord peut-être) des couches les plus hautes d'abstraction. Et j'estime que ça suffit pour donner une réponse simple, claire et propre au problème posé par lemoineo. Ma méthode est peu intrusive, simple à comprendre... Bref...
Maintenant, si j'ai dis des choses fausses, reprend moi (ok, sauf pour le coup de yum, j'avais pas fait attention), et si tu penses que la solution que tu proposais était plus saines que celle que je proposait, alors explique moi en quoi. Je t'ai expliqué mon point de vue de mon coté. Les arguments techniques que tu donnes me perdent, et je n'y ai décelé aucune solution pour le problème de ce fil.