URL: https://linuxfr.org/users/farvardin/journaux/evolution-cass%C3%A9-sur-amd64-comment-revenir-avant Title: Evolution cassé sur AMD64, comment revenir avant ? Authors: B16F4RV4RD1N Date: 2007年10月03日T12:28:18+02:00 Tags: debian Score: 0 bonjour, je sais que cette question aurait plus sa place sur les forums, mais cela impliquait peut-être plus de débat que l'on en trouve dans les forums :) j'utilise quotidiennement Evolution sur une Debian AMD 64. Or, il y a quelques jours, en faisant la mise à jour, j'ai remarqué que quelque chose de bizarre s'était passé, en fait tous les paquets sont mis à jour vers la 2.12 sauf le paquet principal qui reste à la 2.10, comme on le voit ici : [http://packages.debian.org/search?keywords=evolution&sea(...)](http://packages.debian.org/search?keywords=evolution&searchon=names&suite=unstable&section=all) apparemment en regardant dans les bugs, seul i386 est passé à la 2.12 sur tous les paquets, et c'est dû à un problème de compilation sur les autres plateformes. Soit. La première question, c'est quel est l'intérêt de passer une dépendance critique comme evolution-data-server en 2.12 sur amd64, alors que le paquet evolution ne compile pas bien sur cette plateforme ? Du coup j'ai cassé evolution, alors pour pouvoir au moins le lancer j'ai forcé la version 2.10 pour revenir à evolution-common, mais il n'est pas possible de revenir à la 2.10 pour evolution-data-server. Je peux consulter mes messages, mais pas y répondre, je ne peux pas non plus ajouter de nouvelles entrées au carnet d'adresse (crash direct). Tous mes rendez-vous ont disparus à l'affichage, mais apparemment c'est encore dans la base si je fouille dans les fichiers dans .evolution. Pourquoi ne pas bloquer tout ce qui correspond à evolution à la 2.10 pour les architectures autres que i386 ? Pourquoi ne pas avoir laissé les paquets de 2.10 dans les bases de téléchargement si la nouvelle version est cassée ? Sinon savez-vous s'il est possible de vraiment revenir facilement à la version précédente en attendant ? La seconde question, c'est pourquoi faire des dépendances à la noix avec evolution (binaire) d'un côté, evolution-common (données) de l'autre, ce qui fatalement peut mener à ce genre de joyeusetés s'il n'y a pas de garde fou (C'est la même chose pour gimp, gimp-data etc). Je présume que c'est pour gagner de la place sur les serveurs vis à vis des architectures moins courantes, ce qui peut être une bonne chose, mais il faudrait trouver un solution lorsque c'est cassé. De plus, c'est très souvent que si on demande la mise à jour du meta paquet (genre wine, gimp etc), les dépendances nécessaires ne sont pas mises à jour automatiquement, il faut le faire à la main. Mauvaise configuration du mainteneur ? Cela ne le fait pas pour kdelib par exemple qui met à jours toutes les dépendances associées, mais pour gimp il ne le fait que paquet par paquet, si on met à jour gimp, il ne fait pas libgimp2.0). Le modulaire c'est bien (mieux que dans d'autres distributions où si on veut knode on est obligé d'avoir toutes la branche kde-internet-quelquechose avec kmail etc), mais là c'est un peu lourd. C'est la première fois où j'ai un tel problème avec Sid, en tout cas cela n'encourage vraiment pas d'essuyer les plâtres avec les architectures 64 bits, pour le moment le gain du 64 bits je ne l'ai vraiment pas vu, je l'ai surtout mesuré en temps perdu avec ce qui ne fonctionne pas bien...