Je relance le fil avec cette remarque qui me fait reflechir. Je suis dans le meme cas que Snake57 étant un transfuge d’Ubuntu que j’ai pratiqué pendant 7 ans tout de même. Pourquoi la version “testing” serait plus difficile à gerer que la “sid”?. En termes de stabilité n’est-on pas sur le motif :
Stable > Testing > Sid > Experimental ?
… la testing étant la future stable
Il y a là une subtilitié que je ne saisis pas encore. 
[/quote]
http://www.debian.org/doc/FAQ/ch-choosing.fr.html
[quote]3.1.5 Faut-il installer testing ou unstable ?
C’est plutôt subjectif. Il n’existe pas de réponse parfaite mais seulement une « estimation sage » à faire lors du choix entre unstable et testing. L’auteur conseille dans l’ordre de préférence : stable, unstable puis testing. Le problème est le suivant :
Stable est solide comme un roc. Elle est incassable.
Testing est cassée moins souvent que unstable. Mais lorsque cela arrive, la correction met du temps à être appliquée. Des fois il peut s'agir de plusieurs jours, et dans certains cas plusieurs mois.
Unstable change beaucoup, et peut être cassée à n'importe quel moment. Cependant, les problèmes sont souvent corrigés en quelques jours et cette distribution offre toujours les dernières versions des logiciels empaquetés pour Debian.
Pourtant il existe des cas où utiliser testing serait plus avantageux qu’unstable. L’auteur a rencontré ce cas lors de la transition de gcc3 à gcc4. Le paquet labplot était impossible à installer sur une machine unstable car certaines de ses dépendances avaient passé la transition gcc4 et d’autres pas. Au même moment, le paquet de testing était installable sur une machine testing puisque les paquets ayant effectué la transition gcc4 n’avaient pas atteint testing.
3.1.6 Vous parlez de cas où testing est cassée. Qu’entendez-vous par là ?
Parfois, un paquet peut ne pas être installable par les outils de gestion des paquets. Parfois, un paquet peut ne pas être disponible du tout, éventuellement supprimé temporairement en raison de bogues ou de dépendances non résolues. Enfin, un paquet peut s’installer mais ne pas offrir un comportement satisfaisant.
Lorsque cela arrive, on dit que la distribution est cassée (du moins pour ce paquet).
3.1.7 Pourquoi testing peut-elle être cassée pendant plusieurs mois ? Les correctifs introduits dans unstable n’arrivent-ils par directement dans testing ?
Les corrections de bogues et les améliorations introduites dans la distribution unstable atterrissent dans testing après un certain nombre de jours. Disons que ce seuil est de 10 jours. Les paquets d’unstable arrivent dans testing seulement si aucun bogue critique pour la publication (« RC » pour « Release Critical ») n’est signalé à leur égard. Si un bogue RC est signalé sur un paquet d’unstable, il n’entrera pas dans testing avant les 10 prochains jours.
En effet on considère que si le paquet a un problème, celui-ci sera découvert par les utilisateurs d’unstable et sera corrigé avant que le paquet puisse atteindre testing. Cela permet à testing de rester utilisable la plupart du temps. Le concept est génial la plupart du temps, mais les choses ne sont jamais si simples. Considérez par exemple la situation suivante :
Vous êtes intéressé par le paquet XYZ.
Le 10 juin, la version dans testing est XYZ-3.6 et dans unstable XYZ-3.7
10 jours après, XYZ-3.7 migre d'unstable vers testing.
Donc le 20 juin, testing et unstable ont toutes deux XYZ-3.7.
Un utilisateur de la distribution testing repère qu'une nouvelle version de XYZ est disponible et met à jour sa version XYZ-3.6 en XYZ-3.7.
Le 25 juin, quelqu'un utilisant testing ou unstable découvre un bogue RC dans XYZ-3.7 et le signale dans le BTS.
Le responsable de XYZ corrige ce bogue et l'envoie vers unstable le 30 juin. On suppose ici que 5 jours sont nécessaires au responsable pour corriger et envoyer la nouvelle version. Ce chiffre de 5 ne doit pas être pris au pied de la lettre ; il peut être supérieur ou inférieur, suivant la sévérité du bogue RC.
Cette nouvelle version arrivée dans unstable, XYZ-3.8 est programmée pour atteindre testing le 10 juillet.
Mais le 5 juillet, un autre utilisateur découvre un autre bogue dans XYZ-3.8.
Considérons que le responsable de XYZ corrige ce nouveau bogue et envoie la nouvelle version en 5 jours.
Ainsi le 10 juillet, testing propose XYZ-3.7 alors que unstable propose XYZ-3.9.
Cette nouvelle version XYZ-3.9 est reprogrammée pour atteindre testing le 20 juillet.
Puisque vous utilisez testing et que XYZ-3.7 est boggué, vous ne pourrez sans doute utiliser XYZ qu'après le 20 juillet. Ainsi vous aurez passé près d'un mois avec une version XYZ cassée.
La situation peut être bien plus compliquée, si par exemple XYZ dépend de 4 autres paquets. Cela peut rendre la distribution testing inutilisable pendant plusieurs mois. Le scénario ci-dessus est fictif et peut se produire dans la réalité, même si de tels cas sont rares. [/quote]
Pour résoudre les situations où testing est cassée, une solution est d’ajouter les dépôts de sid et stable dans le sources.list. Ce qui permet de prendre un éventuel paquet manquant ou cassé dans sid ou dans stable. Mais ça implique d’avoir un fichier /etc/apt/preferences pour rester en testing, sans ce fichier toute la distribution passerait en sid.
j’aime bien comprendre ce que je fais.
