Les dangers de Debian testing
Par figaro, mardi 22 septembre 2009 à 10:10 :: Debian/Ubuntu :: #89 :: rss
La distribution Debian Testing n'est pas exempte de dangers et certains en ont fait l'expérience récemment à leurs dépends.
Extraits de la FAQ officielle de Debian sur ce sujet :
I - 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.
II - 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 introduits 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 moins 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.
C'est pour cela qu'il ne faut sous testing tant qu'elle n'est pas gelée ne faire que des aptitude safe-upgrade , cela vous sauvera la mise la plupart du temps et toujours faire une simulation au préalable avec l'option -s .
Et si vous tenez absolument à être à jour des dernières nouveautés passez à sid comme le conseille l'auteur des FAQ ainsi que cep, mais cela peut être sportif de temps en temps.

Commentaires
1. Le dimanche 1 novembre 2009 à 13:19, par installation portail
Ajouter un commentaire