Comme dit plus haut, si tu ne sais pas résoudre ce genre de problèmes, il vaut mieux utiliser testing et de l'apt pinning pour récupérer dans unstable les versions de softs que tu veux absolument.
> 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.
# utilise testing et de l'apt pinning ...
Posté par Lucas . En réponse au journal Evolution cassé sur AMD64, comment revenir avant ?. É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.