5 raisons pour lesquelles Debian unstable ne mérite pas son nom

Debian unstable (également connue sous le nom de sid) est l’une des 3 distributions proposées par Debian (les deux autres étant stable et testing).

Elle n’est pas conçue comme un produit pour les utilisateurs finaux, son rôle essentiel est de servir de dépôt pour les toutes dernières versions de paquets envoyés par les contributeurs, et ce quotidiennement. unstable est donc perpétuellement en évolution rapide, et par conséquent pas nécessairement appropriée pour tout public. Ceci étant, il est possible de l’utiliser sans que votre ordinateur n’explose !

1. unstable contient principalement des versions stables de logiciels

Oui oui, vous avez bien lu. unstable ne contient pas tout plein de versions de développement bien que, ponctuellement pour certains logiciels, ce soit le cas. Il s’agit la plupart du temps d’une décision réfléchie de la part du mainteneur de paquets, considérant qu’en l’état cette version particulière est déjà supérieure à l’ancienne.

Ceci s’explique par le fait que sid est l’antichambre de testing, dépôt où la prochaine version stable est préparée. Les mainteneurs ne doivent donc y envoyer que des paquets d’une qualité suffisante en vue de la publication, le reste devant prendre le chemin de experimental.

2. Elle ne crashe pas tous les jours

Des dysfonctionnements surviennent, mais ne sont en règle générale ni sérieux, ni difficiles à corriger. Voilà un bout de temps maintenant qu’il ne m’est pas arrivé, après une mise à jour, de ne plus pouvoir redémarrer mon ordinateur, ou que l’interface graphique soit non fonctionnelle. La plupart du temps, les dysfonctionnements rencontrés prennent la forme d’un logiciel cessant de fonctionner ou souffrant d’un bogue nouveau, ou bien que certains paquets ne puissent plus être installés.

Vous pouvez vous en sortir, dans la grande majorité des cas, en installant la version du paquet incriminé présente dans testing, ou en trouvant dans le suivi des bogues un moyen de contourner le problème. Il est également possible de prévenir plutôt que de guérir : apt-listbugs, en vous prévenant du problème, peut vous dissuader de mettre à jour.

3. Elle est à la base d’autres distributions

Si Debian unstable était de si piètre qualité, elle ne servirait pas de base de départ pour des distributions dérivées. Logique, non ? Deux exemples basées sur sid parmi d’autres : Ubuntu et Sidux Aptosid.

4. Sa conception ne la rend pas moins sécurisée que stable ou testing

Les vulnérabilités importantes sont généralement rapidement corrigées dans stable et unstable. L’équipe chargée de la sécurité s’occupe de stable, tandis que la correction d’unstable revient aux mainteneurs des paquets concernés. testing récupère généralement la correction à travers la mise à jour des paquets provenant d’unstable, entraînant ainsi une latence à l’obtention des corrections.

Les problèmes de sécurités d’importance moindre peuvent n’entraîner aucune correction dans stable. Dans ce cas, les utilisateurs de testing/unstable sont mieux servis, dans la mesure où ils récupèreront la correction avec la nouvelle version du paquet, quoi qu’il arrive.

Bien évidemment, il peut arriver que les mainteneurs soient particulièrement occupés ou que certaines failles arrivent quand même à se faufiler. Si le mainteneur ne réagit pas, d’autres personnes examinant les bogues RC (Release Critical) proposeront les corrections nécessaires.

5. Je l’utilise sur mon ordinateur principal

Et je ne suis pas le seul ! Vous pouvez le faire également si vous remplissez les conditions suivantes :

  • vous savez utiliser la ligne de commande (du moins suffisamment pour rétrograder de version un paquet, éditer des fichiers de configuration, …) ;
  • vous connaissez le fonctionnement d’APT et l’utilisation simultanée de plusieurs dépôts dans /etc/apt/sources.list ;
  • l’anglais lu/écrit n’est pas un problème, de telle sorte que vous pouvez lire/écrire les rapports de bogue, le cas échéant ;
  • vous disposez d’un autre ordinateur relié à Internet, d’où vous pouvez rechercher de la documentation (ou le système de suivi des bogues, ou les listes de diffusion dédiées au support) lorsque votre ordinateur principal est hors service pour une raison qui vous échappe.

Si vous ne vous sentez pas prêt à faire le grand saut, vous pouvez vous abonner à ce blog (ou vous abonner au flux RSS), dans la mesure où je posterai certainement d’autres articles permettant d’acquérir les compétences nécessaires pour y arriver.

PS: Sans renier ce qui précède, si vous avez une installation fonctionnelle de sid, n’allez pas jusqu’à la mettre à jour juste avant une importante présentation, ou un voyage : le crash a toujours lieu au pire moment. À moins que vous ne vous sentiez l’âme d’un aventurier, bien sûr !

Cet article est une traduction de 5 reasons why Debian Unstable does not deserve its name contribuée par Weierstrass01. Suivez moi sur Identi.ca, Twitter et Facebook.

Le processus de publication de Debian expliqué

À l’heure actuelle, le seul et unique but du projet Debian est la parution de sa version stable[1]. Celle-ci intervient généralement tous les 18 à 24 mois, par le biais d’un processus dont cet article va tenter de brosser une vue générale.

Créer une nouvelle distribution

La publication de la nouvelle version stable est immédiatement suivie de la création d’une nouvelle distribution dans l’archive Debian, peuplée précisément par la version fraîchement publiée. Le choix de son nom de baptême revient aux Release Managers et il est de tradition qu’il soit choisi parmi l’un des noms de personnages du film d’animation Toy Story.

Dans le cas qui nous occupe actuellement, Wheezy vient d’être créée, maintenant que Squeeze (ou Debian 6.0) vient d’être publiée.

La distribution utilisée pour préparer la prochaine version stable est par contre toujours nommée testing, dans un souci de simplicité. Dans l’archive Debian, testing n’est qu’un lien symbolique pointant vers le répertoire approprié (wheezy, depuis peu).

Mises à jour des paquets, implémentation des objectifs

Les développeurs sont occupés, pendant la majeure partie du cycle de publication, par l’empaquetage des nouvelles versions amont, ainsi que par l’implémentation des « objectifs de publication » (release goals). L’envoi des paquets se fait d’abord dans l’archive unstable.

De là les paquets migrent vers testing une fois quelques tests de qualité passés : ils ne doivent pas être entachés de bogues critiques pour la publication, être disponibles pour toutes les architectures déjà supportées, ne briser aucune dépendance dans testing et enfin avoir au moins passé 10 jours dans unstable.

Cette période minimale permet d’assurer que le paquet a été testé et que ceux qui ont procédé aux tests ont eu suffisamment de temps pour rapporter les bogues éventuels. Si jamais l’un d’entre eux est critique pour la publication, le paquet est bloqué pour la migration vers testing.

La principale activité de la Release Team consiste pendant cette phase à s’assurer que les mises à jour des paquets migrent de unstable vers testing. Tâche pouvant se révéler ardue : les dépendances entre paquets « lient » souvent ces derniers ensemble, de sorte qu’ils ne puissent migrer vers testing qu’en même temps. Si un seul des paquets n’est pas prêt (par exemple parce que la nouvelle version de l’un d’entre eux n’a pas encore passé les 10 jours réglementaires dans unstable), c’est la migration de tous les paquets liés qui est bloquée.

Stabilisation, finition et correction des bogues critiques pour la publication

L’afflux constant de nouveaux paquets rend difficile la publication d’une version bien « léchée ». C’est la raison pour laquelle, atteint un certain point, les Release Managers gèlent testing : les mises à jour automatiques sont interrompues et chaque mise à jour de chaque paquet est soumise à validation. La sélection est impitoyable, seules sont autorisées les mises à jour corrigeant les bogues critiques pour la publication, ou ceux apportant à la fois une importante plus-value à l’expérience utilisateur (nouvelles traductions, documentation mise à jour, …) tout en présentant de faibles risques d’entraîner des régressions.

Certains paquets sont même retirés durant cette période de gel, si leurs versions actuelles ne seront pas supportées pour toute la durée de vie de la version stable de Debian.

La période de gel tend à ralentir considérablement les changements dans unstable. La plupart des mainteneurs de paquets optent en effet pour l’envoi des nouvelles versions dans experimental, de telle sorte qu’ils puissent toujours mettre à jour leurs paquets dans testing via unstable. Il s’agit là du processus recommandé par les Release Managers, dans la mesure où les mises à jour qu’ils autorisent ont été testées de la manière usuelle. Ce qui n’est pas le cas si elles sont directement envoyées dans testing (via testing-proposed-updates).

Cette caractéristique se révèle plutôt ennuyeuse pour les utilisateurs voulant rester à l’avant-garde en terme de versions de paquets, et qui utilisent testing ou unstable dans cette optique, celle d’une distribution en évolution perpétuelle (rolling release).

Publication

Dès que les Release Managers sont satisfaits de la qualité de la nouvelle distribution, les dernières opérations préalables à la publication sont lancées, telles que la génération des images CD. Dans l’archive Debian, la publication est officialisée par la redirection du lien symbolique de la version stable vers la nouvelle distribution – et celui de la version oldstable vers la désormais ancienne distribution.

Champagne ! Cette boucle est bouclée, une nouvelle peut commencer ! :-)

[1] Le projet « Testing Constamment Utilisable » vise à faire de testing une distribution officiellement supportée, tout comme la version stable, mais avec une politique de mise à jour très différente.

Cet article est une traduction de Understanding Debian’s release process contribuée par Weierstrass01. Ne manquez pas une occasion de parfaire vos connaissances de Debian ou Ubuntu, abonnez-vous à ma newsletter en cliquant ici.