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(...)
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...
Journal Evolution cassé sur AMD64, comment revenir avant ?
3
oct.
2007
# C'est pour ça que...
Posté par Slayne . Évalué à 8.
Le titre me parait assez clair non ??? Si tu ne veux pas essuyer les plâtres, reste en Testing.
Sinon, pour revenir en arrière, tu as plusieurs possibilités :
- rajouter des sources testing dans ton /etc/apt/sources.list et revenir en arrière à l'aide d'aptitude ou synaptic
- reprendre à la main les paquets sous http://snapshot.debian.net/ et quelques coups de dpkg -i
- sûrement d'autres solutions à insérer ici
[^] # Re: C'est pour ça que...
Posté par Slayne . Évalué à 10.
Avec Sid tu risques vraiment de rencontrer bien plus grave que ça, avec parfois un système cassé à la base, et là c'est une autre paire de manche à rattraper.
[^] # Re: C'est pour ça que...
Posté par B16F4RV4RD1N . Évalué à 2.
http://snapshot.debian.net/archive/2007/09/01/debian/pool/ma(...)
sinon je sais parfaitement que sid veut dire "en développement", néanmoins cela fait plus de 3 ans que j'utilise Debian Sid sans jamais avoir eu un problème de cette envergure. D'ailleurs on remarquera que le problème ne touche pas i386. Donc je ne vois pas de raison de passer en testing, qui présente des paquets souvent trop obsolètes à mon goût. Pour faire court, pourquoi je devrais me coltiner des versions anciennes de logiciels (firefox, openoffice, inkscape, gimp etc) alors que sous windows il est possible d'installer la version courante ?
Un système vraiment cassé à la base avec sid, à mon avis cela doit faire longtemps que ce n'est pas arrivé, ou alors j'ai eu de la chance, parce qu'en 3 ans je n'en ai jamais eu, les seuls petits problèmes pouvant se résoudre très facilement.
Par contre je vais installer apt-listbugs, j'ai vu qu'ici certains conseillaient la sid avec ce paquet qui peut prévenir en cas de risque de casse...
même ici par exemple ils ne semblent pas conseiller testing :
http://people.cornell.edu/pages/kk288/debian_choosing_distri(...)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: C'est pour ça que...
Posté par Slayne . Évalué à 2.
[^] # Re: C'est pour ça que...
Posté par Lucas . Évalué à 2.
> la sid avec ce paquet qui peut prévenir en cas de risque de casse...
Si le problème que tu rencontres n'a pas encore été signalé, ca ne va rien changer...
> même ici par exemple ils ne semblent pas conseiller testing :
on ne t'a jamais dit de ne pas croire tout ce que tu lis sur le net ? :-)
[^] # Re: C'est pour ça que...
Posté par zebob . Évalué à 6.
[^] # Re: C'est pour ça que...
Posté par gnumdk (site web personnel) . Évalué à 1.
Moi, j'ai cette solution la:
/dev/sdc3 37G 1,8G 34G 6% /var/cache/apt/archives
Bon, vous me direz faut etre tarer pour avoir une partition de 37G pour apt mais j'ai trop d'espace disque... :)
Non, en fait j'ai quelques disques IDE de rab et mon systeme tourne sur du SATA (un disque principal et un disque identique de réplication des données via mirrordir).
# utilise testing et de l'apt pinning ...
Posté par Lucas . Évalué à 6.
> Or, il y a quelques jours, en faisant la mise à jour, j'ai remarqué que
> quelque chose de bizarre s'était passé
Oui, le maintaineur d'evolution n'a pas mis une "build-dependancy" suffisamment stricte, du coup evolution ne compile pas sur la plupart des architectures. Cf http://packages.qa.debian.org/e/evolution.html
> c'est quel est l'intérêt de passer une dépendance critique comme
> evolution-data-server en 2.12 sur amd64
je ne vois pas où tu as vu cette dépendance. Chez moi, evolution dépend sur e-d-s >= 1.9.4.
> Pourquoi ne pas bloquer tout ce qui correspond à evolution à la 2.10 pour
> les architectures autres que i386 ?
Parce que pour savoir que ca ne marche pas ailleurs que sur i386, il faut bien essayer. Et que l'objectif d'une version de développement, c'est d'aller vers l'avant, parfois en cassant puis réparant des trucs.
> Pourquoi ne pas avoir laissé les paquets de 2.10 dans les bases de
> téléchargement si la nouvelle version est cassée ?
Car un paquet source ne peut exister qu'en une seule version dans une suite (stable, testing, unstable) donnée. C'est déjà assez compliqué comme ça.
> Sinon savez-vous s'il est possible de vraiment revenir facilement à la
> version précédente en attendant ?
Oui, rajoute les sources pour testing, puis:
apt-get install evolution/testing evolution-data-server/testing (+ les autres paquets que tu veux downgrader).
Attention, cette manip n'est pas supposée être supportée.
> 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é.
C'est juste que le paquet n'a pas pû être compilé sur une architecture. Si tu mets à jour à coups de apt-get upgrade (et pas de apt-get dist-upgrade), normalement, tu vas attendre sagement que le paquet soit disponible. Je ne comprends pas bien comment tu as réussi à te mettre dans cette situation.
> 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.
C'est parce que tu ne demandes pas la mise à jour d'un paquet, mais l'installation de la nouvelle version d'un paquet. Si les paquets actuellement installés sont suffisants pour satisfaire les dépendances déclarées par le paquet, pourquoi les mettre à jour ?
Après, si les dépendances déclarées par le paquet sont fausses, c'est un bug. As-tu un exemple où tu as installé une nouvelle version de gimp, où il n'a pas installé de nouvelle version de libgimp2.0, et où après, gimp ne fonctionnait plus ?
> C'est la première fois où j'ai un tel problème avec Sid
T'as eu de la chance jusqu'à maintenant :-) Comme je le disais: testing + apt pinning sont tes amis.
[^] # Re: utilise testing et de l'apt pinning ...
Posté par B16F4RV4RD1N . Évalué à 2.
pour la mise à jour je fais rarement des apt-get upgrade, en général je ne mets à jour que les paquets que j'utilise le plus (gimp, inkscape, openoffice, evolution konqueror etc)
pour l'histoire de la dépendance, je voulais dire que si la dépendance d'evolution passait à la nouvelle version avant evolution lui-même, et que c'était mis à jour ainsi dans la version 64 bits, cela cassait tout (ce n'était pas par rapport à 1.9.4.)
et pour gimp, si cela fonctionnait toujours, mais c'est bizarre de mettre à jour juste une partie du logiciel et pas le reste non ? La mise à jour devrait se faire pour l'ensemble de la version.
En fait je pense que si cela n'avait pas du tout compilé pour i386, le paquet pour 2.12 n'aurait pas du tout sorti, là cela ne passe que pour i386 et pas pour les autres mais la mise à jour s'est quand même faite sur les dépôts pour l'ensemble des architectures.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: utilise testing et de l'apt pinning ...
Posté par Lucas . Évalué à 2.
> juste une partie du logiciel et pas le reste non ? La mise à jour devrait se faire
> pour l'ensemble de la version.
Pas forcément: si tu veux juste mettre à jour un paquet, il va faire le travail minimum pour te permettre de mettre ce paquet à jour.
> En fait je pense que si cela n'avait pas du tout compilé pour i386, le paquet
> pour 2.12 n'aurait pas du tout sorti, là cela ne passe que pour i386 et pas
> pour les autres mais la mise à jour s'est quand même faite sur les dépôts pour
> l'ensemble des architectures.
Non, car evolution-common est un paquet architecture: all, donc pas compilé sur chaque architecture. Mais encore une fois, vu les dépendances, je ne vois pas comment tu t'es débrouillé, car pour installer evolution-common 2.12, il faut forcément désinstaller evolution 2.10...
[^] # Re: utilise testing et de l'apt pinning ...
Posté par B16F4RV4RD1N . Évalué à 2.
(sauf que pour le coup en faisant une mise à jour d'evolution cela ne m'a pas mis à jour evolution-data-server, et en voulant par exemple répondre à un message cela plantait tout evolution)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: utilise testing et de l'apt pinning ...
Posté par benoar . Évalué à 3.
Mais moi j'ai un "problème" : je suis en stable, et j'ai les dépôts testing/unstable avec une priorité moindre. Mais un changement majeur de la libc dans testing fait que je ne peux rien installer, puisqu'à chaque fois il veut mettre à jour la libc.
Bon OK, stable c'est pas fait pour faire mumuse avec les paquets expérimentaux, mais là je suis bien limité dans les "mélanges" possibles.
La solution c'est un apt-get -t unstable source ... et dgpk-buildpackage (ça passe très bien la plupart du temps car la MaJ de la libc n'ajoute apparemment pas grand chose d'utilisé par les programmes). Mais des fois c'est lourd. Faudrait peut-être que j'automatise tout ça...
# BTS ?
Posté par imalip . Évalué à 2.
En fait, ca aurait meme encore plus sa place sur le BTS Debian, histoire que les mainteneurs d'évolution soient informés du probleme (evo 2.12 + e-d-s 1.10) et fassent en sorte que les 2 ne soient pas installés en meme temps.
Il y en a vraiment encore qui croient que le seul fait de passer a 64 bits apporte de la vitesse en plus ?
[^] # Re: BTS ?
Posté par Snarky . Évalué à 4.
Non, mais entre geeks, c'est toujours à celui qui à le plus de bits :p
[^] # Re: BTS ?
Posté par Anonyme . Évalué à 4.
64bits c'est plus de registres processeurs, et rien que ca ca change pas mal de choses. Mais je t'accorde qu'on ne ressent pas tant que ca en utilisation desktop, par contre pour tout ce qui est gros traitement genre multimédia, y'a pas photo.
[^] # Re: BTS ?
Posté par imalip . Évalué à 3.
Euh, oui, c'est bien entendu comme ca qu'il fallait le prendre dans mon post, vu l'utilisation faite par la personne qui a écrit le journal.
Il y a évidemment un certain nombre d'applications ou le gain est loin d'etre négligeable, au hasard le petit cluster dédié a la CFD que j'ai vu ce matin...
[^] # Re: BTS ?
Posté par B16F4RV4RD1N . Évalué à 2.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.