Debian; Cycle de vie d'une release

Traitons d'abord le cas particulier de la distribution Experimental : c'est un ensemble de paquets Debian correspondant à des logiciels en cours de développement et pas forcément finalisés — d'où son nom. Tout ne transite pas par cette étape ; certains développeurs y créent des paquets pour obtenir un premier retour des utilisateurs les plus expérimentés (ou les plus courageux).

Par ailleurs, cette distribution abrite fréquemment des modifications importantes portant sur des paquets de base et dont l'intégration dans Unstable avec des bogues gênants aurait des répercussions trop importantes et bloquantes. C'est donc une distribution totalement isolée, dont les paquets ne migrent jamais vers une autre (sauf intervention expresse du mainteneur ou des ftpmasters). Elle n'est également pas utilisable de manière indépendante : seul un sous-ensemble des paquets existants est présent dans Experimental et elle ne contient généralement pas le système de base. Cette distribution est donc exploitable seulement en combinaison avec une autre distribution indépendante, comme Unstable.

Revenons au cas d'un paquet layout. Le mainteneur crée un premier paquet, qu'il compile pour Unstable et place sur le serveur ftp-master.debian.org. Cette première manifestation implique inspection et validation par les ftpmasters. Le logiciel est alors disponible dans Unstable, la distribution la plus à jour choisie par des utilisateurs préférant le dernier cri à l'assurance de l'absence de bogues graves. Ceux-ci découvrent alors le programme et le testent.

S'ils y découvrent des bogues, ils les décrivent à son mainteneur. Ce dernier prépare alors régulièrement des versions corrigées, qu'il place sur le serveur.

Toute nouvelle mise en ligne est répercutée sur tous les miroirs Debian du monde dans les 6 heures. Les utilisateurs valident alors la correction et cherchent d'autres problèmes, consécutifs aux modifications. Plusieurs mises à jour peuvent ainsi s'enchaîner rapidement. Pendant ce temps, les robots autobuilders sont entrés en action. Le plus souvent, le mainteneur ne dispose que d'un PC traditionnel et aura compilé son paquet pour architecture amd64 (ou i386) ; les autobuilders ont donc pris le relais et compilé automatiquement des versions pour toutes les autres architectures. Certaines compilations pourront échouer ; le mainteneur recevra alors un rapport de bogue signalant le problème, à corriger dans les prochaines versions. Lorsque le bogue est découvert par un spécialiste de l'architecture concernée, il arrive que ce rapport soit accompagné d'un correctif prêt à l'emploi.

Figure 1.2. Compilation d'un paquet par les autobuilders

Un peu plus tard, le paquet aura mûri ; compilé sur toutes les architectures, il n'aura pas connu de modifications récentes. C'est alors un candidat pour l'intégration dans la distribution Testing — ensemble de paquets Unstable sélectionnés sur quelques critères quantifiables. Chaque jour, un programme choisit automatiquement les paquets à intégrer à Testing, selon des éléments garantissant une certaine qualité :

1. 2. 3. 4.

Ce système n'est évidemment pas infaillible ; on trouve régulièrement des bogues critiques dans un paquet intégré à Testing. Il est pourtant globalement efficace et Testing pose beaucoup moins de problèmes qu'Unstable, représentant pour beaucoup un bon compromis entre la stabilité et la soif de nouveauté.

Supposons notre paquet désormais intégré à Testing. Tant qu'il est perfectible, son responsable doit persister à l'améliorer et recommencer le processus depuis Unstable (mais ces inclusions ultérieures dans Testing sont en général plus rapides : à moins d'avoir changé de manière significative, toutes les dépendances sont déjà présentes). Quand il atteint la perfection, son mainteneur a fini son travail et la prochaine étape est l'inclusion dans la distribution Stable, en réalité une simple copie de Testing à un moment choisi par le Release Manager. L'idéal est de prendre cette décision quand l'installateur est prêt et quand plus aucun programme de Testing n'a de bogue critique répertorié.

Étant donné que ce moment ne survient jamais dans la pratique, Debian doit faire des compromis : supprimer des paquets dont le mainteneur n'a pas réussi à corriger les bogues à temps ou accepter de livrer une distribution comptant quelques bogues pour des milliers de logiciels. Le Release Manager aura préalablement prononcé une période de freeze (gel), où il devra approuver chaque mise à jour de Testing. Le but est d'empêcher toute nouvelle version (et ses nouveaux bogues) et de n'approuver que des mises à jours correctives.

Figure 1.3. Parcours d'un paquet au sein des différentes versions de Debian

Après la sortie de la nouvelle version stable, le Stable Release Manager en gère les évolutions ultérieures (appelées « révisions », par ex. : 7.1, 7.2, 7.3 pour la version 7). Ces mises à jour intègrent systématiquement tous les correctifs de sécurité. On y trouve également les corrections les plus importantes (le mainteneur du paquet doit prouver la gravité du problème qu'il souhaite corriger pour faire intégrer sa mise à jour).

À la fin du voyage, notre hypothétique paquet est désormais intégré à la distribution stable. Ce trajet, non dépourvu de difficultés, explique les délais importants séparant les versions stables de Debian. Il contribue surtout à sa réputation de qualité. De plus, la majorité des utilisateurs est satisfaite par l'emploi de l'une des trois distributions disponibles en parallèle. Les administrateurs systèmes, soucieux avant tout de la stabilité de leurs serveurs, se moquent de la dernière version de GNOME ; ils opteront pour Debian Stable et en seront satisfaits. Les utilisateurs finaux, plus intéressés par la dernière version de GNOME ou de KDE que par une stabilité irréprochable, trouveront en Debian Testing un bon compromis entre absence de problèmes graves et logiciels relativement à jour. Enfin, les développeurs et utilisateurs les plus expérimentés pourront ouvrir la voie en testant toutes les nouveautés de Debian Unstable dès leur sortie, au risque de subir les affres et bogues inhérents à toute nouvelle version de logiciel. À chaque public sa Debian !

Figure 1.4. Parcours chronologique d'un paquet logiciel empaqueté par Debian

Chaque version Stable a une durée de vie prévue d'environ 5 ans ; étant donné que les versions stables se succèdent au rythme approximatif d'une tous les 2 ans, il peut y avoir jusqu'à 3 versions supportées à un instant donné. Lorsqu'une nouvelle version stable est publiée, la précédente devient Oldstable et celle d'encore avant devient Oldoldstable.

Le support à long terme (Long Term Support, LTS) des versions de Debian est une initiative récente : des contributeurs individuels et des sociétés joignent leurs forces pour créer l'équipe Debian LTS. Les anciennes versions qui ne sont plus officiellement supportées par l'équipe de sécurité de Debian deviennent la responsabilité de cette nouvelle équipe.

L'équipe de sécurité de Debian s'occupe du support de sécurité de la version actuellement Stable ; elle s'occupe aussi de Oldstable, mais seulement pendant la durée nécessaire pour assurer qu'il y a au moins un an de chevauchement avec la version actuellement stable. Cela correspond approximativement à trois ans de support effectif pour chaque version. L'équipe Debian LTS prend alors la main pour assurer les deux dernières années de support de sécurité, de sorte que chaque version bénéficie d'au moins 5 ans de support et que les utilisateurs puissent migrer d'une version N à la version N+2.